Right. this was another problem. now A both verrsion and B work ok.
Problem in C: org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Package uses conflict: Import-Package: com.something.b.main; version="0.0.0" Is this due to conflict between the imported dependency from to Be and the one imported directly from C? Is this situation supposed to be supported? I mean C using one version of and using B that uses another version of A? How can I accomplish this goal? Any help appreciated. Thanks, Yair On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall <[email protected]>wrote: > On 4/14/10 14:59, Yair Ogen wrote: > >> Added the suggested Export-Package as well as Private-Package for the >> activator. >> >> install fails now on: >> >> org.codehaus.classworlds.NoSuchRealmException: plexus.core >> at >> org.codehaus.classworlds.ClassWorld.getRealm(ClassWorld.java:128) >> at >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:434) >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> >> > > This sounds specific to the scenario you are trying to implement. Not sure, > I have no idea what Class Worlds is... > > -> richard > > > Yair >> >> On Wed, Apr 14, 2010 at 8:42 PM, Richard S. Hall<[email protected] >> >wrote: >> >> >> >>> To include packages without exporting them, you should use >>> Private-Package. >>> For example, you shouldn't export your activator package. >>> >>> Is sounds like you want something like this: >>> >>> CompA v1 >>> Export-Package: com.something.classes; version=1.0.0 >>> >>> CompA v1.0.1 >>> Export-Package: com.something.classes; version=1.0.1 >>> >>> CompB >>> Import-Package: com.something.classes; version="[1.0.0, 1.0.0]" >>> >>> Export-Package: com.something.b.main >>> Private-Package: com.something.activator.b >>> >>> CompC >>> Import-Package: com.something.classes; version="[1.0.1, 1.0.1]", >>> com.something.b.main >>> Private-Package: com.something.activator.c >>> >>> -> richard >>> >>> >>> >>> >>> >>>> Regards, >>>> >>>> Yair >>>> >>>> On Wed, Apr 14, 2010 at 4:40 PM, Richard S. Hall<[email protected] >>>> >>>> >>>>> wrote: >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>> On 4/14/10 9:19, Christopher Brind wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> 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? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Well, as long as you extend that with, ..."and package API separately >>>>> from >>>>> the implementation." >>>>> >>>>> Then, yes, that'd be a good rule of thumb for the average case, since >>>>> it >>>>> would result in the fewest issues overall at the expense of creating >>>>> more >>>>> bundles to manage. >>>>> >>>>> -> richard >>>>> >>>>> >>>>> 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] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
