Resolution Issue with multiple version of Jetty

[castortech]

I tried to upgrade our application from Jetty 9.4.40 to the recent 9.4.56 and things started breaking.

Our environment target imports Jetty 10.0.9 via some Eclipse features, but we are not using those, but it has not been a problem in the past.

Finally I created a minimal project with only a manifest and got the same issue:

Some part of my issue seem to overlap with issue #482 when reading it.

But here is what I found and how I solved it. Being that I only had 3 jetty bundles from 9.4.56 in my manifest, they surely didn't specify a dependency on version 10. So I looked at their manifest and they contained import to match the export. We produce most of our p2 via mvn2p2 which in turn uses bnd to generate the OSGi manifest if not there/compliant. So I edited the manifest to add the version range, here is the example of the change for org.eclipse.jetty.server:

With this change, a reload of target platform then the version 10.0.9 went away for server. I repeated the same process for the other 2 and voilà, problem solved.

Now back to one of my real project and the issue was still there. I finally realized that the only difference was the I had selected an exact match to version 9.4.56 instead of a range as shown here in the dummy project. So I changed to a range and turns out that this was also required.

Then it was more of the same on a number of other jetty bundles until it is now finally operational.

So why is this happening ?
Do import that are made to match export also need to specify a range (btw a version there as well was shown not to work), if so is that a configuration in bnd?
why is the exact match different and not working?

Obviously manually editing bundle manifest is not a usual approach and not very scalable and can be anything but brittle.

Thanks
Alain

[merks]

Some of these dependencies do look kind of bogus even in the latest versions from https://download.eclipse.org/tools/orbit/simrel/maven-jetty/release/12.0.16

It's not unusual to import the provided package exports, but yet it seems strange to me to do that without a version range.

There's also the question here of what happens at runtime (how does OSGi actually wire things) versus what PDE adds as dependencies at development time (where adding all bundles that satisfy the transitive requirements seems reasonable).

Maybe you can avoid the problem if you use package imports instead of bundle requirements; it's maybe worth a try.

In any case, you mention that something breaks. Can you be more specific about what breaks? If it's a runtime problem that's not something PDE can fix. You've also not mentioned which version of PDE you are using, nor provided a way for us to reproduce the problem ourselves...

[castortech]

Hi Ed,
Thanks for the response and here is more info.

It's not unusual to import the provided package exports, but yet it seems strange to me to do that without a version range.

Given your suspicion of strangeness, I went digging and found a 10 year old issue here that covers that. There is a recent issue from Apache commons text that pretty well describes the expected resolution process and indeed the range is needed to avoid the issue that I got here. So the resolution from PDE is not an issue if the range is missing and there is a newer version. I'll have to deal with that one separately.

Maybe you can avoid the problem if you use package imports instead of bundle requirements; it's maybe worth a try.

Well not in this case for sure as I've tried it and we use Import-Package as much as we can, but here it's one of those that is very challenging with PDE and import packages.

In any case, you mention that something breaks. Can you be more specific about what breaks? If it's a runtime problem that's not something PDE can fix. You've also not mentioned which version of PDE you are using, nor provided a way for us to reproduce the problem ourselves...

By breaking I mean that it fails to compile and reports that some methods don't exist for example since it's resolving against version 10 that has made some breaking changes (methods signature change, things removed, etc). As for the PDE version, this is 3.13.2900 from 2024-12.
com.castortech.iris.ba.webviewer3.zip

Given that the range issue is not PDE, the one remaining question/issue is why, with a fixed bundled that has import range, an exact match in my manifest still results in picking version 10 instead of the requested 9.4.56
I have attached the project and put the libs in it directly to allow for an easy setup. At the moment it will fail. If you update the bundle to specify a range, you will see that it then correctly resolves to 9.4.56

Thanks
Alain

[merks]

As I understand it, the dependencies shown by PDE are generally the transitive dependency closure and these unbounded imports of exported packages expands that transitive closure.

I don't think the problem you demonstrate on this example bundle where you've included libraries in the library folder is representative of a meaningful problem. Why? Because those libraries are not even considered as bundles by PDE. Such libraries are just used on the classpath directly in that bundle so the bundle requirement still needs to resolve to a bundle in the target platform. Here when I debug the only jetty bundle that matches by name is jetty 12 which is what Eclipse 4.35 itself is using:

[laeubi]

We have had this issue from time to time.

Long story short:

1. import/export without version is bad
2. usually libraries like jetty will never benefit from imp/export so it should not be done

Why this fails PDE resolution is because an (uncontrained) substitution package will hide the export (see OSGi spec for details) that means that such a bundle is hiding its export effectively.

So assume we have A that exports with version 1 and imports without a range and bundle B that exports with version 2 then this hides the export of A and no other bundle that requires version 1 can every resolve.