[JBoss JIRA] (JBIDE-23413) use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23413?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23413:
-------------------------------
Description:
Because hibernate tools use Require-Bundle instead of Import-Package to depend on slf4j.api, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar when installed via rpm on rhel/fedora.
Here's the line that is causing the problem:
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
We need to switch to using Import-Package to that *any* implementation of this package, regardless of *Bundle-SymbolicName*, can be used.
More info in JBDS-4136
See also:
http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
was:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that any implementation of the package, regardless of *Bundle-SymbolicName*, can be used.
More info in JBDS-4136
See also:
http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
> use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
> ----------------------------------------------------------------------
>
> Key: JBIDE-23413
> URL: https://issues.jboss.org/browse/JBIDE-23413
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate, rpm
> Affects Versions: 4.4.2.AM2
> Reporter: Nick Boldt
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.4.2.AM3
>
> Attachments: org.hibernate.eclipse.unresolved.req.txt
>
>
> Because hibernate tools use Require-Bundle instead of Import-Package to depend on slf4j.api, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar when installed via rpm on rhel/fedora.
> Here's the line that is causing the problem:
> https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
> We need to switch to using Import-Package to that *any* implementation of this package, regardless of *Bundle-SymbolicName*, can be used.
> More info in JBDS-4136
> See also:
> http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
> http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBDS-4136) Uses constraint violation - org.slf4j.api vs. slf4j.api
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4136?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-4136:
-----------------------------
Description:
Latest bit of rpm madness...
This conflict occurred:
{code}
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){code}
So, since slf4j.api is installed via 5 upstream projects (5 symlinks, actually, to rh-java-common):
{code}
$➔ 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
{code}
... 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:
{code}Bundle-SymbolicName: slf4j.api{code}
than the one in devstudio's update site / target platform
{code}Bundle-SymbolicName: org.slf4j.api{code}
NOW, I'm getting this:
{code}
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"
{code}
Snjezana got this too in m2e.core:
{code}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"{code}
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.
was:
Latest bit of rpm madness...
This conflict occurred:
{code}
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){code}
So, since slf4j.api is installed via 5 upstream projects (5 symlinks, actually, to rh-java-common):
{code}
$➔ 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
{code}
... I removed it from the RPM in favour of the other bundle, which was already installed into the fedora/rhel eclipse.
BUT... since this jar exports a different, incompatible bundle name:
{code}Bundle-SymbolicName: slf4j.api{code}
than the one in devstudio's update site
{code}Bundle-SymbolicName: org.slf4j.api{code}
NOW, I'm getting this:
{code}
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"
{code}
Snjezana got this too in m2e.core:
{code}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"{code}
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.
> Uses constraint violation - org.slf4j.api vs. slf4j.api
> -------------------------------------------------------
>
> Key: JBDS-4136
> URL: https://issues.jboss.org/browse/JBDS-4136
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Sub-task
> Components: build, rpm, target-platform
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 10.2.0.AM3
>
>
> Latest bit of rpm madness...
> This conflict occurred:
> {code}
> 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){code}
> So, since slf4j.api is installed via 5 upstream projects (5 symlinks, actually, to rh-java-common):
> {code}
> $➔ 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
> {code}
> ... 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:
> {code}Bundle-SymbolicName: slf4j.api{code}
> than the one in devstudio's update site / target platform
> {code}Bundle-SymbolicName: org.slf4j.api{code}
> NOW, I'm getting this:
> {code}
> 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"
> {code}
> Snjezana got this too in m2e.core:
> {code}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"{code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBDS-4136) Uses constraint violation - org.slf4j.api vs. slf4j.api
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4136?page=com.atlassian.jira.plugin.... ]
Nick Boldt reassigned JBDS-4136:
--------------------------------
Assignee: Nick Boldt
> Uses constraint violation - org.slf4j.api vs. slf4j.api
> -------------------------------------------------------
>
> Key: JBDS-4136
> URL: https://issues.jboss.org/browse/JBDS-4136
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Sub-task
> Components: build, rpm, target-platform
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 10.2.0.AM3
>
>
> Latest bit of rpm madness...
> This conflict occurred:
> {code}
> 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){code}
> So, since slf4j.api is installed via 5 upstream projects (5 symlinks, actually, to rh-java-common):
> {code}
> $➔ 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
> {code}
> ... I removed it from the RPM in favour of the other bundle, which was already installed into the fedora/rhel eclipse.
> BUT... since this jar exports a different, incompatible bundle name:
> {code}Bundle-SymbolicName: slf4j.api{code}
> than the one in devstudio's update site
> {code}Bundle-SymbolicName: org.slf4j.api{code}
> NOW, I'm getting this:
> {code}
> 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"
> {code}
> Snjezana got this too in m2e.core:
> {code}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"{code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23413) use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23413?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23413:
-------------------------------
Description:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that any implementation of the package, regardless of *Bundle-SymbolicName*, can be used.
More info in JBDS-4136
See also:
http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
was:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that any implementation of the package, regardless of bundle, can be used.
More info in JBDS-4136
See also:
http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
> use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
> ----------------------------------------------------------------------
>
> Key: JBIDE-23413
> URL: https://issues.jboss.org/browse/JBIDE-23413
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate, rpm
> Affects Versions: 4.4.2.AM2
> Reporter: Nick Boldt
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.4.2.AM3
>
> Attachments: org.hibernate.eclipse.unresolved.req.txt
>
>
> Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
> https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
> Need to switch to using Import-Package to that any implementation of the package, regardless of *Bundle-SymbolicName*, can be used.
> More info in JBDS-4136
> See also:
> http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
> http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23413) use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23413?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23413:
-------------------------------
Description:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that any implementation of the package, regardless of bundle, can be used.
More info in JBDS-4136
was:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that a ny implementation of the package, regardless of bundle, can be used.
More info in JBDS-4136
> use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
> ----------------------------------------------------------------------
>
> Key: JBIDE-23413
> URL: https://issues.jboss.org/browse/JBIDE-23413
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate, rpm
> Affects Versions: 4.4.2.AM2
> Reporter: Nick Boldt
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.4.2.AM3
>
> Attachments: org.hibernate.eclipse.unresolved.req.txt
>
>
> Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
> https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
> Need to switch to using Import-Package to that any implementation of the package, regardless of bundle, can be used.
> More info in JBDS-4136
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months
[JBoss JIRA] (JBIDE-23413) use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23413?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23413:
-------------------------------
Description:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that any implementation of the package, regardless of bundle, can be used.
More info in JBDS-4136
See also:
http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
was:
Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
Need to switch to using Import-Package to that any implementation of the package, regardless of bundle, can be used.
More info in JBDS-4136
> use Import-Package instead of Require-Bundle for slf4j.api [hibernate]
> ----------------------------------------------------------------------
>
> Key: JBIDE-23413
> URL: https://issues.jboss.org/browse/JBIDE-23413
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate, rpm
> Affects Versions: 4.4.2.AM2
> Reporter: Nick Boldt
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.4.2.AM3
>
> Attachments: org.hibernate.eclipse.unresolved.req.txt
>
>
> Because we use Require-Bundle instead of Import-Package, this project cannot use the rhel implementation (rh-common-java rpm) version of slf4j.api 1.7.4 .jar
> https://github.com/jbosstools/jbosstools-hibernate/blob/master/plugins/or...
> Need to switch to using Import-Package to that any implementation of the package, regardless of bundle, can be used.
> More info in JBDS-4136
> See also:
> http://stackoverflow.com/questions/13959891/why-do-we-need-imported-packa...
> http://stackoverflow.com/questions/1865819/when-should-i-use-import-packa...
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 5 months