I have had a look at the jboss issue. Before going into the long details of my observations I would like a bug report opened against Equinox with the steps to reproduce (what exact version of the VM is used, where to get all the things to install etc). I have not actually tried to reproduce this. It seems the change in the equinox resolver to no longer make special preference of packages exported by the system bundle may be contributing to this issue. That old equinox behavior is not in lines with the OSGi specification and does lead to other types of resolution issues. I deduce this from the following error chain from the resolver:
Unable to resolve resource org.springframework.ide.eclipse.quickfix
[osgi.identity; osgi.identity="org.springframework.ide.eclipse.quickfix";
type="osgi.bundle"; version:Version="3.4.0.201310051539-RELEASE";
singleton:="true"] because it is exposed to package 'javax.xml.ws' from
resources org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"
; type="osgi.bundle"; version:Version="3.10.0.v20140121-0337"; singleton:=
"true"] and javax.xml.ws [osgi.identity; osgi.identity="javax.xml.ws";
type="osgi.bundle"; version:Version="2.1.0.v200902101523"] via two
dependency chains.
Chain 1:
org.springframework.ide.eclipse.quickfix [osgi.identity; osgi.identity=
"org.springframework.ide.eclipse.quickfix"; type="osgi.bundle";
version:Version="3.4.0.201310051539-RELEASE"; singleton:="true"]
require: (osgi.wiring.bundle=org.eclipse.core.runtime)
|
provide: osgi.wiring.bundle: org.eclipse.core.runtime
org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type=
"osgi.bundle"; version:Version="3.10.0.v20140121-0337"; singleton:="true"]
Chain 2:
org.springframework.ide.eclipse.quickfix [osgi.identity; osgi.identity=
"org.springframework.ide.eclipse.quickfix"; type="osgi.bundle";
version:Version="3.4.0.201310051539-RELEASE"; singleton:="true"]
require: (osgi.wiring.bundle=org.springframework.web)
|
provide: osgi.wiring.bundle; osgi.wiring.bundle=
"org.springframework.web"; bundle-version:Version="4.0.0.20130829-M3"
org.springframework.web [osgi.identity; osgi.identity=
"org.springframework.web"; type="osgi.bundle"; version:Version=
"4.0.0.20130829-M3"]
import: (&(osgi.wiring.package=javax.xml.ws)(version>=0.0.0))
|
export: osgi.wiring.package: javax.xml.ws
javax.xml.ws [osgi.identity; osgi.identity="javax.xml.ws"; type=
"osgi.bundle"; version:Version="2.1.0.v200902101523"]
This indicates to me that org.springframework.web is exporting some package
that uses javax.xm.ws AND org.springframework.web got wired to the
javax.xml.ws package exported by the javax.xm.ws bundle. What is not
indicated is the package version of javax.xml.ws, but if this is the orbit
bundle (which it seems to be from the version) then the package version is
2.1.0. The resolver prefers packages with a higher version and the
system.bundle exports the javax packages with no version (because as of yet
nobody knows what version of these packages the various versions of the VM
have). So the resolver picks the higher 2.1.0 version package javax.xml.ws
for resolving the org.springframework.web bundle.
org.springframework.ide.eclipse.quickfix is using require-bundle (sigh,
here we go) for the org.eclipse.core.runtime bundle, which inturn
re-rexports org.eclipse.osgi (yes, re-export is evil!). In Equinox
org.eclipse.osgi is the system.bundle so that means it is exporting
javax.xml.ws depending on the Java SE version you are running on. This is
how org.springframework.ide.eclipse.quickfix is getting exposed to the two
different versions of javax.xml.ws. If we had instead preferred the
system.bundle export of javax.xml.ws for the Import-Package from
org.springframework.web then it is likely this scenario would have resolved
OK in Luna.
Another thing that is contributing to this situation is the fact that we
changed to doing incremental resolves in Equinox instead of "big bang" in
order to avoid exploding the uses constraint resolve process when we have
large sets of bundles [1]. This effectively locks in previous decisions we
made when resolving each bundle one at a time. This is likely why the
org.springframework.web bundle gets wired to the higher javax.xml.ws
package and "locked in" without the ability to back off that decision later
when we are trying to resolve org.springframework.ide.eclipse.quickfix
At the end of the day there are things the resolve may be able to do to
help, but the real issue is the situation the spring bundles have
introduced by using require bundle for org.eclipse.core.runtime. Also
changing the resolver to help in this scenario likely will cause issues in
other scenarios. One simple change to help would be for the
org.springframework.ide.eclipse.quickfix bundle to use Import-Package for
the javax.xml.ws packages they need that are used by
org.springframework.web.
Tom
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=421706#c10
From: Snjezana Peco <snjeza.p...@gmail.com>
To: Equinox development mailing list <equinox-dev@eclipse.org>,
Date: 03/14/2014 06:13 AM
Subject: [equinox-dev] Problem exporting packages on Luna
Sent by: equinox-dev-boun...@eclipse.org
Hi,
Spring IDE (the org.springframework.web plugin) exports the javax.xml.ws
and javax.xml.bind package.
If a Luna distribution includes the javax.xml.ws and javax.xml.bind
plugin, no one plugin depending on the org.springframework.web plugin
will be started.
Luna reports there are two chains for the javax.xml.ws and
javax.xml.bind package.
The issue doesn't happen on Kepler.
Is this a bug or expected behaviour?
See more details in https://issues.jboss.org/browse/JBDS-2956
Thanks,
Snjeza
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
