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
Snjezana Peco ---03/14/2014
06:13:04 AM---Hi, Spring IDE (the org.springframework.web
plugin) exports the javax.xml.ws
From: Snjezana Peco
<snjeza.peco@xxxxxxxxx>
To: Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>,
Date: 03/14/2014 06:13 AM
Subject: [equinox-dev] Problem exporting
packages on Luna
Sent by: equinox-dev-bounces@xxxxxxxxxxx
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
