Eliminate "Legacy" Bundle about orbit HOT 13 CLOSED

I'm starting to wonder now about "everything has sources". I don't find sources for org.apache.wsil4j anywhere. So if there were a security problem, we'd be completely hosed and could not produce new binaries?

from orbit.

I'm down to these legacy dependencies:

The selected projects are source bundles that can be used to replace the legacy bundles, along with wsil4j for which no source exists and which appears to be repackaged from an older binary in repo.eclipse.org by EBR (and is a disaster waiting to happen, in my opinion).

from orbit.

If I build that locally and replace the old Orbit EBR repo with that repo, the aggregation succeeds (with sources) like this:

from orbit.

Here is the prototype temporarily checked into my personal repository:

https://github.com/merks/orbit-legacy/

It's built by this:

https://ci.eclipse.org/orbit/job/orbit-simrel-orbit-legacy

and published here:

https://download.eclipse.org/tools/orbit/test/orbit-legacy/

from orbit.

@jonahgraham

I opened this iplab issue to ensure that we're properly following any and all applicable rules:

https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/9823

from orbit.

Shall I create a new orbit-legacy Git repository with the initial contents as outlined above to produce a p2 repository https://download.eclipse.org/tools/orbit/simrel/orbit-legacy that can then be used in the aggregation to replace using an actual older orbit ebr repository?

+1

Do you have any questions or concerns?

No concerns.

I want to point out how Orbit has handled items missing on Maven Central in the past, see https://github.com/eclipse-orbit/orbit/blob/main/Add-bundle.md#library-not-available-on-maven-central

That approach was simple - but has the obvious problem of little to no reproduciblty as the jars uploaded were built on user's machines.

I am not advocating for maintaining that going forward, but it is an important part of the historical puzzle .

from orbit.

It seems that the new org.apache.axis bundle is no longer a combination of org.apache.axis:axis:1.4 and org.apache.axis:axis-ant:1.4 as before, and now only contains the main axis artifact, breaking the webtools.webservices build. If the axis-ant content can be added back (technically I think it's more correct as its own bundle?), I think I can resolve that problem on my end.

from orbit.

@nitind

Sorry about that. I had no idea that was the case and should have looked more closely at the old bundle. I don't think the maven-location approach can combine two libraries into one. Providing a separate org.apache.axis.ant bundle is easy though and I think that does make more sense...

from orbit.

Thanks @merks , I've pushed changes adding with the new bundle in mind. The other failures I mentioned in passing are from org.junit failing to find org.hamcrest by package name and version; I do not know if it is related to that now being a split package.

from orbit.

Note that I've rebuilt newer versions of today that should more closely (exactly) match what was produced before based on this discussion:

eclipse-orbit/orbit-simrel#5

from orbit.

We don't seem to be at the drop-in replacement stage yet.

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:4.0.0:validate-classpath (default-validate-classpath) on project org.eclipse.wst.common.snippets.tests: Execution default-validate-classpath of goal org.eclipse.tycho:tycho-compiler-plugin:4.0.0:validate-classpath failed: org.osgi.framework.BundleException: Bundle org.eclipse.wst.common.snippets.tests cannot be resolved:org.eclipse.wst.common.snippets.tests [113]
[ERROR]   Unresolved requirement: Require-Bundle: org.junit; bundle-version="3.8.2"
[ERROR]     -> Bundle-SymbolicName: org.junit; bundle-version="4.13.2.v20230725-0701"
[ERROR]        org.junit [107]
[ERROR]          Unresolved requirement: Import-Package: org.hamcrest; version="1.3.0"
[ERROR] -> [Help 1]

from orbit.

The org.junit bundles has these two things:

Import-Package                          org.hamcrest.core;version="1.3"
                                        org.hamcrest;version="1.3"
Manifest-Version                        1.0
Originally-Created-By                   Apache Maven 3.1.1
Require-Bundle                          org.hamcrest.core;bundle-version="1.3.0";resolution:=optional;visibility:=reexport;x-installation:=greedy

The older version had a non-optional requirement on org.hamcrest.core, but there is a new bundle org.hamcrest version 2.2 that will also make org.junit happy and we want people to migrate to that newer one.

The Xtext build and the Platform build had the same and I told them make sure that org.hamcrest.core is explicitly in the target platform so that worked for both those builds.

In the worst case, just include the old org.junit in your target platform for now and that can be fixed later... After all, the version of org.junit in SimRel is determined by the Platform and RAP:

so it won't really matter exactly which one you use in your build...

from orbit.

@nitind

I've gone through what look like ancient javax things here and systematically found jakarta replacements for this:

I've filtered out all javax bundle coming from orbit ebr.

The nightly build has all the replacements:

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest/index.html

Including for the really ancient legacy things for which there was no source.

If there is something ancient that you still need, please open an issue requesting what's missing.

from orbit.