replace require-bundle with import-package for org.glassfish.jersey.core.jersey-client and -common

[nickboldt]

When installed on RHEL 7 or Fedora into an rpm-installed Eclipse Oxygen.1a installation, org.springframework.ide.eclipse.boot.wizard causes a constraint violation when starting up Eclipse, as javax.annotation-api 1.2.0 and org.eclipse.osgi 3.12.1 are both present and provide conflicting dependency resolution chains.

I think the fix here is to replace these require-bundle requirements [1] for org.glassfish.jersey.core.jersey-client and -common with import-package ones, so that different package providers can be used on different OSes and the duplicate bundle provider need not be installed in addition to the RPM-provided ones.

[1] https:/spring-projects/spring-ide/blob/master/plugins/org.springframework.ide.eclipse.boot.wizard/META-INF/MANIFEST.MF#L36-L37

More info here:

• https://issues.jboss.org/secure/attachment/12426720/12426720_rh-eclipse47-devstudio4.7.1-5.2.el7.log.20171024-1353_strict.txt
• https://issues.jboss.org/browse/JBDS-4595?focusedCommentId=13481402&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13481402

[martinlippert]

The question here is whether we need the dependency altogether here. javax.ws.rs loads classes from the glassfish jersey bundles, but it seems like this is done in some dynamic way rather that through the regular bundle dependencies.

Therefore I could imagine to solve this my removing that dependency altogether and add those jersey bundles to the feature definition instead (to make sure they are around when the spring tools get installed).

What do you think about that?

[nickboldt]

Switching to a feature-based dependency model won't help the problem here, and in fact that's worse because it moves the dependency out of the plugin itself and into a wrapper, making the dep only available to developers if they happen to look into the feature. IMHO features are a dead construct, only still relevant for collecting a group of plugins together to make installation easier. They're still needed for Eclipse Marketplace and other Mylyn Discovery-based applications, but for normal p2 update sites built with Tycho, they're entirely obsolete as you can add <bundle/>s to category.xml directly now.

That aside, depending on the bundles, be it in MANIFEST.MF or feature.xml, will still cause p2 to install a plugin that provides the same packages as a system-installed rpm, leading to conflicting dependency chains and preventing the spring boot wizard plugin from being activated on Eclispe startup.

The solution is to depend on PACKAGES, rather than BUNDLES. I'll try to concoct a PR later today if I can.

[martinlippert]

Yeah, okay, I see what you mean. Installing the jersey plugins altogether by a feature or a bundle dependency will cause the issue, right? Since this dependency is really needed by the javax.ws.rs bundle (at runtime), it might be hard to find out which packages are the right ones to depend on (since it is an artificial dependency anyway), but we can take a look, for sure.

[nickboldt]

Thanks, Martin. FWIW, this isn't the first time I've reported such a problem (with a relatively easy fix). https:/spring-projects/spring-ide/pull/81/files

It's becoming an annual tradition. :)

[martinlippert]

Yeah, I know. And they are very very welcome!!! Keep them coming!!!

[martinlippert]

294ae3e

Now lets wait a moment until the CI builds are done and update site with this change are available for you to double check.

[martinlippert]

Here is a nightly build p2 repo of the full STS distro, if you want to give it a try: http://dist.springsource.com/snapshot/TOOLS/nightly/e4.7

Let me know if this works and if not, we can re-open this issue.

[nickboldt]

Thanks for the quick fix! However, the problem persists after installing org.springframework.ide.eclipse.feature_3.9.2.201710261819-CI-B1862 and org.springframework.ide.eclipse.boot.wizard 3.9.2.201710261819-CI-B1862.

Maybe it's that you require-bundle to org.eclipse.core.runtime and org.eclipse.osgi, rather than importing packages you actually require?

Or, maybe the issue is that you have a few uses:="javax.annotation" constraints in your Export-Bundle directives?

Looking in these plugins:

• ./io.projectreactor.reactor-core_3.0.7.201706071909-RELEASE/META-INF/MANIFEST.MF
• ./org.springframework.context_4.3.0.20160611-RELEASE/META-INF/MANIFEST.MF
• ./org.springframework.ide.eclipse.beans.core.autowire_3.9.2.201710261819-CI-B1862/META-INF/MANIFEST.MF

Related ... I'm wondering if there's a problem in our rpm install, in that we have two versions of org.glassfish.jersey.core.jersey-common.

g! ss org.glassfish.jersey.core.jersey-common

id State Bundle
1467 RESOLVED org.glassfish.jersey.core.jersey-common_2.23.2
1468 INSTALLED org.glassfish.jersey.core.jersey-common_2.22.1.v20161103-1916

I'm only able to activate one of them, the newer one. When I try to activate the 2.21.1 version, I get a similar use constraint issue dumped to the console:

g! start 1468
org.osgi.framework.BundleException: Could not resolve module: org.glassfish.jersey.core.jersey-common [1468]
Unresolved requirement: Import-Package: org.osgi.framework; version="[4.2.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: sun.misc; resolution:="optional"
Bundle was not resolved because of a uses contraint violation.
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.glassfish.jersey.core.jersey-common [osgi.identity; osgi.identity="org.glassfish.jersey.core.jersey-common"; type="osgi.bundle"; version:Version="2.22.1.v20161103-1916"] because it is exposed to package 'javax.annotation' from resources javax.annotation-api [osgi.identity; osgi.identity="javax.annotation-api"; type="osgi.bundle"; version:Version="1.2.0"] and org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.12.1.v20170917-1608"; singleton:="true"] via two dependency chains.

Chain 1:
org.glassfish.jersey.core.jersey-common [osgi.identity; osgi.identity="org.glassfish.jersey.core.jersey-common"; type="osgi.bundle"; version:Version="2.22.1.v20161103-1916"]
import: (&(osgi.wiring.package=javax.annotation)(&(version>=1.2.0)(!(version>=2.0.0))))
|
export: osgi.wiring.package: javax.annotation
javax.annotation-api [osgi.identity; osgi.identity="javax.annotation-api"; type="osgi.bundle"; version:Version="1.2.0"]

Chain 2:
org.glassfish.jersey.core.jersey-common [osgi.identity; osgi.identity="org.glassfish.jersey.core.jersey-common"; type="osgi.bundle"; version:Version="2.22.1.v20161103-1916"]
import: (&(osgi.wiring.package=jersey.repackaged.com.google.common.base)(&(version>=2.22.0)(!(version>=3.0.0))))
|
export: osgi.wiring.package=jersey.repackaged.com.google.common.base; uses:=javax.annotation
org.glassfish.jersey.bundles.repackaged.jersey-guava [osgi.identity; osgi.identity="org.glassfish.jersey.bundles.repackaged.jersey-guava"; type="osgi.bundle"; version:Version="2.22.1.v20161103-1916"]
import: (osgi.wiring.package=javax.annotation)
|
export: osgi.wiring.package: javax.annotation
org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.12.1.v20170917-1608"; singleton:="true"]

[martinlippert]

Hey Nick, I looked at this again and analyzed the error message that you posted in more details. From what I can see there is an issue with the jersey bundles and their usage of javax.annotation.

The bundle org.glassfish.jersey.bundles.repackaged.jersey-guava imports javax.annotation without a version constraint and can get wired to javax.annotation coming from org.eclipse.osgi.

The bundle org.glassfish.jersey.core.jersey-common also has an Import-Package for the javax.annotation package, but with a version constraint. Since org.eclipse.osgi exports javax.annotation without a version, it gets version 0.0.0 and therefore cannot be used for the import of the jersey-common bundle.

I am not sure yet why the runtime doesn't resolve the repackaged guava lib against the versioned export of javax.annotation. There might be a good reason that I haven't found yet. Do you have an idea why this happens?

[martinlippert]

From my running STS instance I can also see that most usages of the javax.annotation package are wired against the export from org.eclipse.osgi, only the jersey bundles seem to get wired against the javax.annotation export from the separate bundle.

[martinlippert]

Looks like the solution to this problem is causing a different one:
spring-projects/sts4#202

[martinlippert]

@nickboldt do you have any idea how to solve this? Looks like having the import-package statement solves your issue, but causes the other one and vice versa. Any thoughts?

[nickboldt]

@jeffmaury have you encountered this problem when moving to a newer version of STS in Devstudio's Central target platform?

[martinlippert]

@nickboldt @jeffmaury please note that this issue doesn't happen at build time, you can nicely put all those bundles together into the same environment, but it doesn't work at runtime anymore.

From what I analyzed it looks like the bundle oracle.eclipse.tools.rest.lib embeds and provides javax.ws.rs packages as well as the Jersey packages (without a package-use constraint on them). Since we rely on a newer version of javax.ws.rs (to get the .ext packages, too, which are not contained in that oracle bundle), our bundle gets wired to javax.ws.rs from Orbit as well as the Jersey variant from oracle.eclipse.tools.rest.lib, causing a LinkageError when calling the ClientBuilder.

So I would need to restrict our bundle to depend on javax.ws.rs bundle AND a compatible Jersey bundle, which could be done by reverting the change made here and add a Require-Bundle again on the specific Jersey bundle - which would result in the error this bug was filed for. Sounds like a chicken-egg problem to me.

[martinlippert]

I might have found a solution to this via setting a version constraint on the jersey import on our wizard plugin. Can you double check and verify that this still works in your case and the setting that caused the error described here?

To get the latest CI build, choose the right p2 repo URL from here: https://dist.springsource.com/snapshot/STS/nightly-distributions.html

Would be good to know that this change doesn't break your use case again.

[nickboldt]

Just saw this today. I've messaged @jeffmaury via https://issues.jboss.org/browse/JBIDE-26565 to ask if he plans to update to 3.9.8 for the upcoming release of devstudio 12.11.

[jeffmaury]

@nickboldt what's the scenario to test because I tested the Spring Starter Project wizard with our latest build (12.11.0.AM1) on which I installer SpringIDE 3.9.7 and I was able to generate a project.

[nickboldt]

@jeffmaury You need to try 3.9.8, not 3.9.7.

[martinlippert]

@nickboldt @jeffmaury This can be quite tricky to test, since the issue appears only in specific scenarios and specific class loading orders. Could be that one workflow works, the other one not. I think we should still think about the underlying issue described here (if that is still the case, haven't looked at it recently):

From what I analyzed it looks like the bundle oracle.eclipse.tools.rest.lib embeds and provides javax.ws.rs packages as well as the Jersey packages (without a package-use constraint on them). Since we rely on a newer version of javax.ws.rs (to get the .ext packages, too, which are not contained in that oracle bundle), our bundle gets wired to javax.ws.rs from Orbit as well as the Jersey variant from oracle.eclipse.tools.rest.lib, causing a LinkageError when calling the ClientBuilder.

I found a workaround for this in the Spring IDE bundle dependencies, so using Spring IDE 3.9.8 versions and beyond should just work fine, but the issue above is still there and sounds to me like a little time bomb for the next piece using jersey and java.ws.rs.

Thoughts?