Hello Matt,
First could I say that I do wish you luck and success with your project… but
you might find things go more smoothly if you had talked to somebody earlier on
when you began to have problems! Emailing this list of people, late on a Friday
evening just before your enormously important project gets canned… well, it
feels a bit spammy.
Nevertheless, I think I can help. The numbers following the dots in the bundle
IDs are the bundle *revision* numbers. For background on this, read chapter 7
of the new OSGi R4.3 Core specification… but to put it simply, the revision
number goes up each time you update a bundle. So when you see this:
com.hcsc.ccsp.common.om.common [215.0]
com.hcsc.ccsp.common.om.common [215.5]
… those are actually different bundles, so far as the resolution algorithm is
concerned. That's why there are two chains and two exports of the same package.
It looks like you have updated the bundle at least five times without ever
performing a refresh, and some importers are still wired to the original
[215.0] revision.
Remember that OSGi does NOT go around tearing down import/export wirings merely
because a new version of a bundle has been installed! In order to trigger a
re-wiring operation you MUST do a refresh… this is necessary because you may be
doing a batch of multiple updates/installs, and the framework doesn't know when
you are finished.
Hopefully the problem should be solved simply by typing "refresh". Please let
us know how it goes.
Regards
Neil
On Friday, 7 October 2011 at 21:44, Matt Madhavan wrote:
> Hello,
> I'm running into some strange uses constraint issues! I'm involved in a
> rather large Enterprise application for my client. There are multiple
> developers both in the States and India involved in this! This could be one
> of the largest Enterprise OSGi project ever!
>
> As Niel Bartlett put it here
> http://njbartlett.name/2011/02/09/uses-constraints.html
> this may make or break my client's adaptation of OSGi technology for their
> enterprise development. Any help will be appreciate as I would like to solve
> this and keep a tight lid on the OSGi development.
>
> The following is the output from KARAF:
>
> Error executing command: Unable to resolve module
> com.hcsc.ccsp.common.om.claim [214.6] because it is exposed to package
> 'com.hcsc.ccsp.common.om.common.babjo.occurs' from com.hcsc
> .ccsp.common.om.common [215.5] and com.hcsc.ccsp.common.om.common [215.0] via
> two dependency chains.
>
> Chain 1:
> com.hcsc.ccsp.common.om.claim [214.6]
> import:
> (&(package=com.hcsc.ccsp.common.om.common.babjo.occurs)(version>=1.0.0)(!(version>=2.0.0)))
> |
> export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
> com.hcsc.ccsp.common.om.common [215.5]
>
> Chain 2:
> com.hcsc.ccsp.common.om.claim [214.6]
> import:
> (&(package=com.hcsc.ccsp.common.om.common.babjo)(version>=1.0.0)(!(version>=2.0.0)))
> |
> export: package=com.hcsc.ccsp.common.om.common.babjo;
> uses:=com.hcsc.ccsp.common.om.common.babjo.occurs
> export: package=com.hcsc.ccsp.common.om.common.babjo.occurs
> com.hcsc.ccsp.common.om.common [215.0]
>
>
>
> Both babjo and babjo.occurs are in the same bundle. Their version is
> 1.0.0.M1-SNAPSHOT. Both the chains resolve to the same version of the package
> any way so as Neil Bartlet puts it in the com.hcsc.ccsp.common.om.claim class
> space there should be only version of *.babjo.occurs! Any ideas?
>
> The following are my questions:
> 1. Why are even two chains here?
> 2. When the uses constraint is generated does it have a version or its just
> 0.0.0?
> 3. [215.5] - 215 I understand is the bundle id! what is .5 and .0 imply?
> 4. Can some one point me to some good document on this?
>
> Any help will be greatly appreciated! If I get any help I may come in this
> w,e and fix the issues. There are multiple issues like this!
>
> Thanks in advance!
>
> Thanks
> Matt
>
>
