Thanks for your reply. 1. If I omit the Export-Package I get a build error on mvn install with error that jar is empty. Why? 2. I tried to export explicitly just the packages within compB and compC. But now I get this error:
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: com.something.classes; version="1.0.0" com.something.classes is the package that holds Person in compA. this is the relevant part of my pom files: compA version 1.0.0: <configuration> <instructions> <Bundle-Activator>com.something.activator.a.CompAActivator</Bundle-Activator> <Import-Package>org.osgi.framework</Import-Package> <Export-Package>com.something.*</Export-Package> </instructions> </configuration> compA version 1.0.1: <configuration> <instructions> <Bundle-Activator>com.something.activator.a.CompAActivator</Bundle-Activator> <Import-Package>org.osgi.framework</Import-Package> <Export-Package>com.something.*</Export-Package> </instructions> </configuration> compB: <configuration> <instructions> <Bundle-Activator>com.something.activator.b.CompBActivator</Bundle-Activator> <Import-Package>org.osgi.framework,com. something.classes;version="1.0.0"</Import-Package> <Export-Package>com.something.b.main,com.something.activator.b</Export-Package> </instructions> </configuration> compC: <configuration> <instructions> <Bundle-Activator>com.something.activator.c.CompCActivator</Bundle-Activator> <Import-Package>org.osgi.framework,com.something.classes;version="1.0.1",com.something.b.main;version="1.0.0"</Import-Package> <Export-Package>com.something.activator.c</Export-Package> </instructions> </configuration> do you see any problem? 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] > >
