On 4/14/10 13:27, Yair Ogen wrote:
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?
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<he...@ungoverned.org>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<he...@ungoverned.org> 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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
