Hi Richard, Would you agree that a good rule of thumb (subject to specific circumstance of course) is that bundles should only import packages OR export packages, but not both?
Cheers, Chris On 14 April 2010 14:13, Richard S. Hall <[email protected]> wrote: > Technically, what you want to do is possible assuming that CompB doesn't > expose CompA v1 to CompC. From the sounds of it, you've packaged your > bundles incorrectly. Don't embed the Person package into your bundles, > package them as separate bundles and them use Import-Package in the client > bundles to access them. You might want to start with some introductory OSGi > tutorials to understand the basics. > > -> richard > > > On 4/14/10 6:53, Yair Ogen wrote: > >> Hi, >> >> I am a newbie. I've created dummy projects to test this out. >> >> What I am trying to achieve is as follows: >> >> CompA version 1.0.0 defines class Person that has 2 properties: name, >> lastName >> CompA version 1.0.1 defines class Person that has 2 properties: name, >> myLastName >> CompB version 1.0.0 calls API on person compiled with CompA version 1.0.0. >> CompC version 1.0.0 calls API on person compiled with CompA version 1.0.1. >> Additionally calls API on CompB. >> >> So, CompA, both versions, are not dependent on anything. >> CompB is dependant on CompA version *1.0.0*. >> CompC is dependant on CompB version 1.0.0 and CompA version *1.0.1*. >> >> When I read about OSGi I thought that I should be able to see that the API >> used directly between C and A will activate Person from A version 1.0.1, >> but >> the API called from C to B to A will activate the person from A version >> 1.0.0. >> >> This is not the case. Pure B API activate the "right" person. >> >> Person used from C (regardless of the origin - API in C or API in B) >> activates the same Person - 1.0.1. >> >> When investigating I saw that the person class was embedded in B and in C, >> so of course they can only work with one class at a time. >> >> My question is - isn't there a non embedded approach, where both A >> versions >> jars are in the classpath and the container will pick up the correct >> dependency on the fly? >> >> This must work for me, because this is the heart of what I need from OSGi >> - >> Manage multiple version of the same artifacts in a single jvm... >> >> Regards, >> >> Yair >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
