OSGi version resolution
OSGi version resolution looks great, but there is a problem that I am encountering. I can deploy more than one version of a jar as seperate OSGi bundles, but unless the consuming bundle was explicity written to specify a range of versions that bundle will not start.
Bundle A was built with a dependency on package org.apache.commons.useful;version=1.0.2, which means any version > 1.0.2.
I deploy bundle B with org.apache.commons.useful version 1.0.4, great no problem.
Bundle C depends on org.apache.commons.usefull;version=1.0.8,
So I deploy bundle D with 1.0.8, great for Bundle C, but now Bundle A can see 1.0.4 and 1.0.8 and wont start, due to a constraint violation.(at least in Felix).
To make this work I have to go back to bundle A, and rebuild it with version=”[1.0.2,1.0.8)” meaning “I depend on any version >= 1.0.2 and < 1.0.8|. Thats all fine, but, now every time I add a second version of a jar to OSGi, I have to go back and repackage all the bundles that dont have precise enough version numbers.
You might argue 1.0.4 and 1.0.8 are equivalent so dont deploy bundle B anymore, but the same problem happens when you try and deploy bundles container 2.0.6 and 2.5.5 when 2.5.5 is not fully backwards compatable.
Worse, this also means if I took any 3rd party bundles without precise version ranges, I will have to work out how to rebuild them. Not exactly and inviting task when you have > 100 bundles in a container. Makes me wonder if its worth all the hassle.
Comments
3 Responses to “OSGi version resolution”
Leave a Reply
There must be more going on here than you describe, I think. Since there should be no constraint violation unless there is some sort of dependency between bundles A and C. Ultimately, you have to give more details to know what is going on. If you installed all four bundles, B would likely never get used in the first place, since the highest version of the package would get chosen in D.
Post a message on the users@felix mailing list with more details and I am sure there is a reasonable explanation.
Sounds like something else is going on - just because there are >2 versions of a package available shouldn’t stop Bundle A from resolving. Have you mentioned this on the Felix mailing list?
FYI, some people use the following version style:
“[x.y.z, x+1)” ie. “[1.3.0,2)”
where x signifies an incompatible API change. ie: the minimum should be what you test against, and the maximum should be where the next incompatible API change will be.
Ok so I will be a bit more precise about what A,B,C,D are.
A is a bundle that depends on Spring 2.0.6, and that was specified with ;version=2.0.6
B is a bundle containing Spring 2.0.6
C is SpringDM 1.1.1 which depends on Spring >= 2.5
D is Spring Beans version 2.5.5.A
When A starts is I get log messages of the form
14 == A
3 == D
13 == B
C started Ok.
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans from [3.0] and org.springframework.beans from [13.0]
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans from [3.0] and org.springframework.beans from [13.0]
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans from [3.0] and org.springframework.beans from [13.0]
DEBUG: Constraint violation for 14.0 detected; module can see javax.transaction.xa from [13.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 14.0 detected; module can see javax.transaction.xa from [13.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 14.0 detected; module can see javax.transaction.xa from [13.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 14.0 detected; module can see javax.transaction.xa from [13.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans.factory.xml from [3.0] and org.springframework.beans.factory.xml from [13.0]
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans.factory.xml from [3.0] and org.springframework.beans.factory.xml from [13.0]
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans.factory.xml from [3.0] and org.springframework.beans.factory.xml from [13.0]
DEBUG: Constraint violation for 14.0 detected; module can see org.springframework.beans.factory.xml from [3.0] and org.springframework.beans.factory.xml from [13.0]
its quite possible with all the SpringDM extenders and everything else there is something wierd gong on, I will mention it on the Felix lists.
I have found that the autostart load order is relevant.
If I start all of the SPring 2.0.6 and dependencies first, then no problem, but if I start SpringDM and Spring 2.5.5.A first, I get the problems.