Use import-package instead of require-bundle for third-party dependencies

[jonahgraham]

There are a number of places in xtext where 3rd party code is referenced in MANIFEST.MF with require-bundle. This is causing xtext to force pull-in the Orbit version of these bundles when ideally it should accept the more modern way of packaging them with direct from maven.

For example https://github.com/eclipse/xtext/blob/5f36672f56901e1479a2bdd234fdc1974e759ed1/org.eclipse.xtext.xtext.wizard/META-INF/MANIFEST.MF#L17

There is nothing to do immediately, but when updating soon to the newest set of dependencies (hopefully during the 2023-09 release cycle) changing these dependencies would be great.

See https://github.com/eclipse/orbit/issues/25 and https://github.com/eclipse/orbit/pull/44

[cdietrich]

@jonahgraham @merks what is the official solution to get stuff into simrel maven As i indicated before my time is very very sparse And I still don’t trust consuming the feature directly Is there any plans to ship it with all distros ?

[cdietrich]

@jonahgraham also: is there a possibility to achieve https://github.com/eclipse/xtext/blob/5f36672f56901e1479a2bdd234fdc1974e759ed1/org.eclipse.xtext.p2repository/category.xml#L41 with import package?!?

we also have imports in feature.xmls. what is the replacement there?

https://github.com/eclipse/xtext/blob/5f36672f56901e1479a2bdd234fdc1974e759ed1/org.eclipse.xtext.runtime.feature/feature.xml#L27

we have also require bundles that we reexport? how to deal with that (without out breaking the whole world)

[cdietrich]

Manifest change done. Other problems still open

[merks]

I think you are relying on "includes" to ensure that the included bundle is actually in your p2 repository, right? When that's the case, I don't believe there are all that many useful alternatives to including the bundle via the bundle's symbolic name. You could tell p2 to include all transitive requirements but then you pull in JDT, the entire Platform, EMF, and goodness knows what, which I'm sure you don't want.

So yes, there are places where you need to use the bundle symbolic name and if that changes for a direct-from-maven dependency then you are pretty much stuck using the new symbolic name.

[merks]

FYI, there is yet another version of Guava published:

https://repo1.maven.org/maven2/com/google/guava/guava/32.1.1-jre/

I'm currently migrating the Oomph incubator stuff to Orbit and I have these transient repositories:

https://download.eclipse.org/tools/orbit/test/maven-osgi/nightly/N202307021223/index.html

Also PGP signing is not yet possible with Orbit's CI instances so the above are also not yet PGP signed.