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)
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]
>
>
