Hi Neil, Sorry I absolutely did not try to create spam situation. The guys in the list are the folks I have been following and respect them as well.
At my client there are multiple companies involved in the same project - with their interests as well. So it was kind of easy to blame on OSGi for everything. No project is not on the verge of canned. Its been humming along- just wanted to stop the whispers and other things becoming major issues. I appreciate your help. yes the Refresh worked great.Sorry am still kind of new to Karaf. Thanks again and will read the spec you sent below! Matt On Fri, Oct 7, 2011 at 4:10 PM, Neil Bartlett <[email protected]> wrote: > 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 > > > >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
