[JBoss JIRA] (JBIDE-23300) OpenShift connection created by CDK server adapter does not store password in secure storage
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23300?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-23300.
---------------------------------
Resolution: Done
I've pushed a fix. Seems we basically just needed to connect to the connection because no other API exists for properly saving the details. Strange, but it fixed it.
> OpenShift connection created by CDK server adapter does not store password in secure storage
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-23300
> URL: https://issues.jboss.org/browse/JBIDE-23300
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, openshift
> Affects Versions: 4.4.1.Final
> Reporter: Aurélien Pupier
> Assignee: Rob Stryker
> Labels: connection
> Fix For: 4.4.2.AM3
>
>
> OpenShift 3 connection created by a CDK server adapter does not successfully store password in secure storage although a checkbox in the Connection dialog is checked.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-23300) OpenShift connection created by CDK server adapter does not store password in secure storage
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23300?page=com.atlassian.jira.plugi... ]
Rob Stryker reassigned JBIDE-23300:
-----------------------------------
Assignee: Rob Stryker (was: Jeff MAURY)
> OpenShift connection created by CDK server adapter does not store password in secure storage
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-23300
> URL: https://issues.jboss.org/browse/JBIDE-23300
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, openshift
> Affects Versions: 4.4.1.Final
> Reporter: Aurélien Pupier
> Assignee: Rob Stryker
> Labels: connection
> Fix For: 4.4.2.AM3
>
>
> OpenShift 3 connection created by a CDK server adapter does not successfully store password in secure storage although a checkbox in the Connection dialog is checked.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[JBoss JIRA] (JBDS-4132) Could not load nodeJSInstall: node-v0.10.22-linux-x86_64
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-4132?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-4132:
--------------------------------------
This is the failing code - https://github.com/angelozerr/tern.java/blob/tern.java-1.1.0/eclipse/tern...
The problem is that Tern.java tries to extract node-v0.10.22-linux-x86_64.zip bundled with tern.eclipse.ide.server.nodejs.embed.linux.gtk.x86_64 to the bundle location folder which is in /opt/rh/rh-eclipse46/root/usr/... and it fails because of lack of permissions.
Tern should extract nodejs in user's worspace folder instead.
So, Tern java 1.1.0 won't work if installed via RPM :(
cc: [~azerr]
> Could not load nodeJSInstall: node-v0.10.22-linux-x86_64
> --------------------------------------------------------
>
> Key: JBDS-4132
> URL: https://issues.jboss.org/browse/JBDS-4132
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Sub-task
> Components: build, rpm
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Fix For: 10.2.0.AM3
>
>
> Snippet from the log attached to JBDS-4131:
> {code}!ENTRY tern.eclipse.ide.server.nodejs.core 4 0 2016-10-21 14:34:24.958
> !MESSAGE Could not load nodeJSInstall: node-v0.10.22-linux-x86_64
> !STACK 0
> java.io.FileNotFoundException: /opt/rh/rh-eclipse46/root/usr/share/eclipse/droplets/devstudio/eclipse/plugins/tern.eclipse.ide.server.nodejs.embed.linux.gtk.x86_64_1.1.0.201511082254/node-v0.10.22-linux-x86_64/LICENSE (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
> at tern.utils.ZipUtils.extract(ZipUtils.java:83)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstall.<init>(NodejsInstall.java:56)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstallManager.addNodejsInstalls(NodejsInstallManager.java:132)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstallManager.loadNodejsInstalls(NodejsInstallManager.java:117)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstallManager.getNodejsInstalls(NodejsInstallManager.java:69)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceConstants.useBundledNodeJsInstall(TernNodejsCorePreferenceConstants.java:91)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceConstants.initializeDirectAccess(TernNodejsCorePreferenceConstants.java:70)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceConstants.initializeDefaultValues(TernNodejsCorePreferenceConstants.java:45)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceInitializer.initializeDefaultPreferences(TernNodejsCorePreferenceInitializer.java:24)
> at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper$1.run(PreferenceServiceRegistryHelper.java:298)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.runInitializer(PreferenceServiceRegistryHelper.java:301)
> at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:131)
> at org.eclipse.core.internal.preferences.PreferencesService.applyRuntimeDefaults(PreferencesService.java:370)
> at org.eclipse.core.internal.preferences.DefaultPreferences.applyRuntimeDefaults(DefaultPreferences.java:222)
> at org.eclipse.core.internal.preferences.DefaultPreferences.load(DefaultPreferences.java:276)
> at org.eclipse.core.internal.preferences.EclipsePreferences.create(EclipsePreferences.java:370)
> at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:623)
> at org.eclipse.core.internal.preferences.DefaultPreferences.node(DefaultPreferences.java:147)
> at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.getDefaultPreferences(PreferenceForwarder.java:134)
> at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.getString(PreferenceForwarder.java:663)
> at tern.eclipse.ide.core.preferences.PreferencesSupport.getWorkspacePreferencesValue(PreferencesSupport.java:115)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferencesSupport.isNodejsRemoteAccess(TernNodejsCorePreferencesSupport.java:147)
> at tern.eclipse.ide.server.nodejs.internal.core.TernNodejsServerFactory.isRemoteAccess(TernNodejsServerFactory.java:67)
> at tern.eclipse.ide.server.nodejs.internal.core.TernNodejsServerFactory.create(TernNodejsServerFactory.java:35)
> at tern.eclipse.ide.internal.core.TernServerType.createServer(TernServerType.java:90)
> at tern.eclipse.ide.internal.core.resources.IDETernProject.getTernServer(IDETernProject.java:161)
> at tern.resources.TernFileSynchronizer.ensureSynchronized(TernFileSynchronizer.java:160)
> at tern.eclipse.ide.internal.ui.EditorActivationTracker$2.run(EditorActivationTracker.java:85)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> !ENTRY tern.eclipse.ide.core 4 0 2016-10-21 14:34:27.182
> !MESSAGE java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> !STACK 0
> tern.TernException: java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> at tern.eclipse.ide.internal.core.resources.IDETernFileUploader$1.onError(IDETernFileUploader.java:133)
> at tern.server.nodejs.NodejsTernServer.request(NodejsTernServer.java:131)
> at tern.eclipse.ide.internal.core.resources.IDETernFileUploader.run(IDETernFileUploader.java:124)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: tern.server.nodejs.process.NodejsProcessException: java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> at tern.server.nodejs.process.internal.NodejsProcess.start(NodejsProcess.java:245)
> at tern.server.nodejs.process.AbstractNodejsProcess.start(AbstractNodejsProcess.java:144)
> at tern.server.nodejs.NodejsTernServer.getBaseURL(NodejsTernServer.java:202)
> at tern.server.nodejs.NodejsTernServer.makeRequest(NodejsTernServer.java:139)
> at tern.server.nodejs.NodejsTernServer.request(NodejsTernServer.java:127)
> ... 2 more
> Caused by: java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at tern.server.nodejs.process.internal.NodejsProcess.start(NodejsProcess.java:232)
> ... 6 more
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.<init>(UNIXProcess.java:247)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 7 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[JBoss JIRA] (JBDS-4132) Could not load nodeJSInstall: node-v0.10.22-linux-x86_64
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-4132?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-4132:
--------------------------------------
cc: [~vrubezhny]
> Could not load nodeJSInstall: node-v0.10.22-linux-x86_64
> --------------------------------------------------------
>
> Key: JBDS-4132
> URL: https://issues.jboss.org/browse/JBDS-4132
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Sub-task
> Components: build, rpm
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Fix For: 10.2.0.AM3
>
>
> Snippet from the log attached to JBDS-4131:
> {code}!ENTRY tern.eclipse.ide.server.nodejs.core 4 0 2016-10-21 14:34:24.958
> !MESSAGE Could not load nodeJSInstall: node-v0.10.22-linux-x86_64
> !STACK 0
> java.io.FileNotFoundException: /opt/rh/rh-eclipse46/root/usr/share/eclipse/droplets/devstudio/eclipse/plugins/tern.eclipse.ide.server.nodejs.embed.linux.gtk.x86_64_1.1.0.201511082254/node-v0.10.22-linux-x86_64/LICENSE (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
> at tern.utils.ZipUtils.extract(ZipUtils.java:83)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstall.<init>(NodejsInstall.java:56)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstallManager.addNodejsInstalls(NodejsInstallManager.java:132)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstallManager.loadNodejsInstalls(NodejsInstallManager.java:117)
> at tern.eclipse.ide.server.nodejs.internal.core.NodejsInstallManager.getNodejsInstalls(NodejsInstallManager.java:69)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceConstants.useBundledNodeJsInstall(TernNodejsCorePreferenceConstants.java:91)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceConstants.initializeDirectAccess(TernNodejsCorePreferenceConstants.java:70)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceConstants.initializeDefaultValues(TernNodejsCorePreferenceConstants.java:45)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferenceInitializer.initializeDefaultPreferences(TernNodejsCorePreferenceInitializer.java:24)
> at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper$1.run(PreferenceServiceRegistryHelper.java:298)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.runInitializer(PreferenceServiceRegistryHelper.java:301)
> at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:131)
> at org.eclipse.core.internal.preferences.PreferencesService.applyRuntimeDefaults(PreferencesService.java:370)
> at org.eclipse.core.internal.preferences.DefaultPreferences.applyRuntimeDefaults(DefaultPreferences.java:222)
> at org.eclipse.core.internal.preferences.DefaultPreferences.load(DefaultPreferences.java:276)
> at org.eclipse.core.internal.preferences.EclipsePreferences.create(EclipsePreferences.java:370)
> at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:623)
> at org.eclipse.core.internal.preferences.DefaultPreferences.node(DefaultPreferences.java:147)
> at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.getDefaultPreferences(PreferenceForwarder.java:134)
> at org.eclipse.core.internal.preferences.legacy.PreferenceForwarder.getString(PreferenceForwarder.java:663)
> at tern.eclipse.ide.core.preferences.PreferencesSupport.getWorkspacePreferencesValue(PreferencesSupport.java:115)
> at tern.eclipse.ide.server.nodejs.internal.core.preferences.TernNodejsCorePreferencesSupport.isNodejsRemoteAccess(TernNodejsCorePreferencesSupport.java:147)
> at tern.eclipse.ide.server.nodejs.internal.core.TernNodejsServerFactory.isRemoteAccess(TernNodejsServerFactory.java:67)
> at tern.eclipse.ide.server.nodejs.internal.core.TernNodejsServerFactory.create(TernNodejsServerFactory.java:35)
> at tern.eclipse.ide.internal.core.TernServerType.createServer(TernServerType.java:90)
> at tern.eclipse.ide.internal.core.resources.IDETernProject.getTernServer(IDETernProject.java:161)
> at tern.resources.TernFileSynchronizer.ensureSynchronized(TernFileSynchronizer.java:160)
> at tern.eclipse.ide.internal.ui.EditorActivationTracker$2.run(EditorActivationTracker.java:85)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> !ENTRY tern.eclipse.ide.core 4 0 2016-10-21 14:34:27.182
> !MESSAGE java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> !STACK 0
> tern.TernException: java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> at tern.eclipse.ide.internal.core.resources.IDETernFileUploader$1.onError(IDETernFileUploader.java:133)
> at tern.server.nodejs.NodejsTernServer.request(NodejsTernServer.java:131)
> at tern.eclipse.ide.internal.core.resources.IDETernFileUploader.run(IDETernFileUploader.java:124)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: tern.server.nodejs.process.NodejsProcessException: java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> at tern.server.nodejs.process.internal.NodejsProcess.start(NodejsProcess.java:245)
> at tern.server.nodejs.process.AbstractNodejsProcess.start(AbstractNodejsProcess.java:144)
> at tern.server.nodejs.NodejsTernServer.getBaseURL(NodejsTernServer.java:202)
> at tern.server.nodejs.NodejsTernServer.makeRequest(NodejsTernServer.java:139)
> at tern.server.nodejs.NodejsTernServer.request(NodejsTernServer.java:127)
> ... 2 more
> Caused by: java.io.IOException: Cannot run program "node" (in directory "/home/lvalach/rpm-workspace/StaticWebProject"): error=2, No such file or directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at tern.server.nodejs.process.internal.NodejsProcess.start(NodejsProcess.java:232)
> ... 6 more
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.<init>(UNIXProcess.java:247)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 7 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[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 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.
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}
Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
{code}
(Snjezana got this too, ie:
{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
> 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
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[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 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}
Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
{code}
(Snjezana got this too, ie:
{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}
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 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
> 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}
> Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
> {code}
> (Snjezana got this too, ie:
> {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
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[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 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}
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 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}
And 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}
Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
{code}
So... not sure what to do to solve this. :(
> 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
> 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}
> 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 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
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[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 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}
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 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}
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 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
> 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}
> 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 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
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[JBoss JIRA] (JBDS-4131) Can't import example project after RPM installation on RHEL 7
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4131?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4131:
----------------------------------
See JBDS-4136 for discussion around the above uses constraint violation and what we might be able to do to fix that.
> Can't import example project after RPM installation on RHEL 7
> -------------------------------------------------------------
>
> Key: JBDS-4131
> URL: https://issues.jboss.org/browse/JBDS-4131
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm
> Affects Versions: 10.2.0.AM3
> Environment: RHEL Server 7.2.
> Reporter: Lukáš Valach
> Assignee: Snjezana Peco
> Fix For: 10.2.0.AM3
>
> Attachments: DevstudiErrorLog.txt, devstudio10.2.wtf.png, devstudio10.2.wtf2.png, import_wizard.png, maven-wizard-devstudio10.2-rpm-busted.png, maven.importer.error.log, rh-eclipse46-devstudio.repo
>
>
> During the test of RPM installation on RHEL 7 I noticed that I can't import HTML5 example project from central. Only the window with message "Refreshing project examples" appear for a while and then nothing happens.
> There is one warning and many errors in Error Log View.
> Error log export: [^DevstudiErrorLog.txt]
> I also tried to import project from file system, but there isn't the "Existing Maven Project" option in the import wizard. [^import_wizard.png]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
- 1
- 0
[JBoss JIRA] (JBDS-4136) Uses constraint violation - org.slf4j.api vs. slf4j.api
by Nick Boldt (JIRA)
Nick Boldt created JBDS-4136:
--------------------------------
Summary: 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
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}
And 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}
Unresolved requirement: Require-Bundle: org.slf4j.api; bundle-version="1.6.2"
{code}
So... not sure what to do to solve this. :(
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
- 1
- 0