-
Bug
-
Resolution: Done
-
Major
-
10.2.0.AM2
-
None
Latest bit of rpm madness...
This conflict occurred:
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.m2e.wtp.jpa [931] Bundle was not resolved because of a uses contraint violation. org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.eclipse.m2e.wtp.jpa [osgi.identity; type="osgi.bundle"; version:Version="1.3.1.20160831-1005"; osgi.identity="org.eclipse.m2e.wtp.jpa"; singleton:="true"] because it is exposed to package 'org.slf4j' from resources org.slf4j.api [osgi.identity; type="osgi.bundle"; version:Version="1.7.2.v20121108-1250"; osgi.identity="org.slf4j.api"] and slf4j.api [osgi.identity; type="osgi.bundle"; version:Version="1.7.4"; osgi.identity="slf4j.api"] via two dependency chains. Chain 1: org.eclipse.m2e.wtp.jpa [osgi.identity; type="osgi.bundle"; version:Version="1.3.1.20160831-1005"; osgi.identity="org.eclipse.m2e.wtp.jpa"; singleton:="true"] require: (osgi.wiring.bundle=org.slf4j.api) | provide: osgi.wiring.bundle: org.slf4j.api org.slf4j.api [osgi.identity; type="osgi.bundle"; version:Version="1.7.2.v20121108-1250"; osgi.identity="org.slf4j.api"] Chain 2: org.eclipse.m2e.wtp.jpa [osgi.identity; type="osgi.bundle"; version:Version="1.3.1.20160831-1005"; osgi.identity="org.eclipse.m2e.wtp.jpa"; singleton:="true"] require: (osgi.wiring.bundle=org.slf4j.api) | provide: osgi.wiring.bundle; bundle-version:Version="1.7.2.v20121108-1250"; osgi.wiring.bundle="org.slf4j.api" org.slf4j.api [osgi.identity; type="osgi.bundle"; version:Version="1.7.2.v20121108-1250"; osgi.identity="org.slf4j.api"] require: (&(osgi.wiring.bundle=ch.qos.logback.classic)(&(bundle-version>=1.0.7)(!(bundle-version>=1.0.8)))) | provide: osgi.wiring.bundle; bundle-version:Version="1.0.7.v20121108-1250"; osgi.wiring.bundle="ch.qos.logback.classic" ch.qos.logback.classic [osgi.identity; type="osgi.bundle"; version:Version="1.0.7.v20121108-1250"; osgi.identity="ch.qos.logback.classic"] import: (&(osgi.wiring.package=org.slf4j)(version>=1.7.0)) | export: osgi.wiring.package: org.slf4j slf4j.api [osgi.identity; type="osgi.bundle"; version:Version="1.7.4"; osgi.identity="slf4j.api"] at org.eclipse.osgi.container.Module.start(Module.java:444) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
So, since slf4j.api is installed via 5 upstream projects (5 symlinks, actually, to rh-java-common):
$➔ find . -name "*slf4j.api*jar" -exec ls -l {} \;
lrwxrwxrwx 1 root root 81 Oct 11 13:00 ./share/eclipse/droplets/jgit/eclipse/plugins/slf4j.api_1.7.4.jar -> ../../../../../../../../../rh-java-common/root/usr/share/java/slf4j/slf4j-api.jar
lrwxrwxrwx 1 root root 81 Oct 12 05:19 ./share/eclipse/droplets/linuxtools-docker/eclipse/plugins/slf4j.api_1.7.4.jar -> ../../../../../../../../../rh-java-common/root/usr/share/java/slf4j/slf4j-api.jar
lrwxrwxrwx 1 root root 81 Oct 11 14:46 ./share/eclipse/droplets/egit-egit/eclipse/plugins/slf4j.api_1.7.4.jar -> ../../../../../../../../../rh-java-common/root/usr/share/java/slf4j/slf4j-api.jar
lrwxrwxrwx 1 root root 75 Oct 21 09:58 ./share/eclipse/droplets/mylyn-versions-git/eclipse/plugins/slf4j.api_1.7.4.jar -> ../../../../../../../../../rh-java-common/root/usr/share/java/slf4j/api.jar
lrwxrwxrwx 1 root root 81 Oct 11 14:46 ./share/eclipse/droplets/egit-mylyn/eclipse/plugins/slf4j.api_1.7.4.jar -> ../../../../../../../../../rh-java-common/root/usr/share/java/slf4j/slf4j-api.jar
... I removed it from the RPM in favour of the other bundle, which was already installed into the fedora/rhel eclipse.
BUT... since this RH SCL rh-java-common slf4j-api.jar exports a different, incompatible bundle name:
Bundle-SymbolicName: slf4j.api
than the one in devstudio's update site / target platform
Bundle-SymbolicName: org.slf4j.api
NOW, I'm getting this:
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.m2e.wtp.jpa [931]
Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
Snjezana got this too in m2e.core:
BundleException: Could not resolve module: org.eclipse.m2e.core.ui [866] Unresolved requirement: Require-Bundle: org.eclipse.m2e.maven.runtime; bundle-version="[1.7.0,1.8.0)" -> Bundle-SymbolicName: org.eclipse.m2e.maven.runtime; bundle-version="1.7.0.20160603-1931"; singleton:="false" org.eclipse.m2e.maven.runtime [876] Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
So... not sure what to do to solve this.
I suppose the best case would be for the m2e and w2e-wtp bundles to depend on the slf4j.api PACKAGES instead of BUNDLES, so that they can run on the fedora/rhel versions instead of those from the devstudio update site / target platform.
- blocks
-
JBDS-4131 Can't import example project after RPM installation on RHEL 7
- Closed
-
JBDS-4134 missing require-bundles in rpm install
- Closed
- relates to
-
JBDS-4183 Installing from an update site into rpm install causes duplicate IUs to be installed - use constraint violations ensue
- Closed
-
JBIDE-23413 use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
- Closed
-
JBDS-4149 Run Browsersim > java.lang.NoClassDefFoundError: javax/servlet/Servlet on exit
- Closed
-
JBIDE-23414 use Import-Package instead of Require-Bundle for slf4j.api [central]
- Closed
-
JBIDE-23415 use Import-Package instead of Require-Bundle for slf4j.api [livereload]
- Closed
-
JBIDE-22581 Create and use Neon.1 target platform
- Closed
- links to