Hi Sandro, It's difficult to reconstruct because you haven't listed all relevant imports/exports, but I *think* this is the situation:
1) Your bundle 98 imports 2 packages: o.apache.taglibs.standard.tag.rt.fmt AND javax.servlet.jsp.jstl.fmt. Let's abbreviate these rt.fmt and jstl.fmt. 2) There is a uses constraint: rt.fmt uses jstl.fmt. 3) Bundle 94 exports rt.fmt and imports jstl.fmt version [1.1.2,2.0.0). Because of the version range, bundle 94 has wired to the available export jstl.fmt version 1.2. 4) Your bundle 98 wants to import rt.fmt from bundle 94 but it cannot due to the uses constraint from point (2) above: it must import jstl.fmt from the same exporter that bundle 94 imports it from. There appear to be several solutions to this problem: a) Why is your import range of package jstl.fmt so tight?? Do you *really* require only and exactly version 1.1.2 of the package?? Please read up on the concept of Semantic Versioning in OSGi. As a consumer of the jstl.fmt API you should probably use a range like [1.1.2,2.0), i.e. like bundle 94 (taglibs.standard). b) Why have you installed two versions of the jstl bundle? You don't seem to need the 1.2.0 version so why not just uninstall it? While OSGi *can* handle multiple versions of the same export, it does make life more complicated and easily leads to situations such as this. Keep things simple unless you really have a need for both versions to be present. c) If you install both your bundle (jcrbrowser) and the taglibs.standard bundle at the same time before resolving either of them, then the Framework should try to pick the wiring that allows them both to resolve. It looks like you installed and resolved taglibs.standard first -- which resulted in it wiring up to the highest available package export of jstl.fmt -- and then later installed jcrbrowser, resulting in the uses constraint violation. Wherever possible, install/uninstall bundles in batches *before* attempting to resolve or start any of them. Hope this helps. Regards, Neil On Monday, 27 February 2012 at 07:52, Sandro Boehme wrote: > Hello, > > the problem seems to be simple: > My bundle declared two package dependencies (package A and B) with > always one specific version version="[1.1.2,1.1.2]". > The problem seems to be, that B has a dependency to A with > version="[1.1.2, 2.0.0)" of A. When deploying my bundle, B gets wired to > version 1.2.0.v20110728 of A and my bundle doesn't resolve because it > expects version 1.1.2 of A. > See http://www.wingsuit.de/transitive_dependency.jpg > At runtime B has the choice to use the latest version of A that nobody > needs (what it does) or to use the one that is > actually imported by my dependent bundle. I wonder why it uses the first > option. > > I set the import statements for A before B to try if the order is > relevant but that didn't change anything. I guess I got something wrong > or don't know something about how OSGi works. I checked the OSGi spec > but couldn't find a solution. Is there any declaration that I overlooked? > I know the question is not specific to Felix but I would appreciate it a > lot if anybody has a hint on how I could proceed to resolve the > dependency! In case the problem is described in "OSGi in > Action" I would bye the book. > > In case it's needed there is some detailed background: > I'm developing a node browser application ("jcrbrowser") for Sling that > is written in JSP's with JSTL-EL. When I upload the > two dependencies from http://ebr.springsource.com/repository > com.springsource.javax.servlet.jsp.jstl-1.1.2.jar (A in my example) and > com.springsource.org.apache.taglibs.standard-1.1.2.jar (B in my example) > manually via the Management Console everything works fine. > It doesn't work with other versions of those two jars. > I would like to provide the jcrbrowser as a bundle in an OBR to make it > easy for users to install it in Sling with its dependencies. > So I declared all the jstl dependency as package imports like this: > Import-Package: javax.servlet.jsp.jstl.fmt;version="[1.1.2,1.1.2]" > and all the taglibs.standard dependency similar: > org.apache.taglibs.standard;version="[1.1.2,1.1.2]"... > Then I added my obr for my bundle and the > obr from Spring that provides the two bundles > (http://sigil.codecauldron.org/spring-external.obr) to Sling (Felix) and > deployed my bundle. > > The result of "start 98" is: > org.osgi.framework.BundleException: Constraint violation for package > 'javax.servlet.jsp.jstl.fmt' when resolving module 98.0 > between existing import 95.0.javax.servlet.jsp.jstl.fmt BLAMED ON > [[98.0] package; > (&(package=javax.servlet.jsp.jstl.fmt)(version>=1.1.2)(version<=1.1.2))] > and uses constraint 99.0.javax.servlet.jsp.jstl.fmt BLAMED ON [[98.0] > package; > (&(package=org.apache.taglibs.standard.tag.rt.fmt)(version>=1.1.2)(version<=1.1.2)), > > > [94.0] package; > (&(package=javax.servlet.jsp.jstl.fmt)(version>=1.1.2)(!(version>=2.0.0)))] > > I understand it as: > "Constraint violation for package '...jstl.fmt' when resolving > jcrbrowser, expecting jstl.fmt version 1.1.2 but bundle jstl(99) wired a > higher version to bundle taglibs standard (94)." > > Where > 98=jcrbrowser > 94=taglibs.standard (B) > 99=jstl bundle 1.2.0.v20110728 (A) > 95=jstl bundle 1.1.2 (A) > > 94 taglibs.standard: > Import-Package: > org.apache.taglibs.standard.tag.common.fmt;version="[1.1.2, 2.0.0)" > > 99 jstl bundle-version 1.2.0.v20110728: > Export-Package: > javax.servlet.jsp.jstl.fmt;version="1.2.0.v20110728";uses:="javax.servlet.http,javax.servlet.jsp" > > 95 jstl bundle-version 1.1.2: > Export-Package: > javax.servlet.jsp.jstl.fmt;version="1.1.2";uses:="javax.servlet.jsp" > > Best, > > Sandro > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > (mailto:[email protected]) > For additional commands, e-mail: [email protected] > (mailto:[email protected]) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
