You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Yair Ogen <ya...@gmail.com> on 2010/04/14 12:53:20 UTC
embedded dependencies
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
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/18/10 0:37, Yair Ogen wrote:
> I see you point.
>
> Isn't this a common issue where you want to freeze an interface
> implementation version? How can this be achieved?
>
I am not sure I understand your question. If the interface is the same
for all clients, then they can use whatever version of the
implementation, since they are not coupled to the implementation, only
the interface.
> Scenario where both CompB and CopmpC are clients of API in CompA - is common
> enough.
>
> Isn't a requirement that when CompC uses CompA directly it gets impl1 and
> when CompB uses CompA it uses impl2 - regardless to the source of invocation
> (CompC or any other component) also common?
>
This has nothing to do with "the source of invocation" it has to do with
collaborating components. Components can only collaborate through a
common set of types. Any types passed around among collaborating
components (i.e., the types they use to collaborate) must be the same
version of that type for all collaborating components. If a given type
is not used as part of their collaboration, then the components are free
to use whatever version of that type they want. That's all there is to it.
-> richard
> On Sun, Apr 18, 2010 at 1:30 AM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 4/17/10 14:31, Yair Ogen wrote:
>>
>>
>>> Well, htis might be it.
>>>
>>> CompB imports a class from CompA.
>>>
>>> So, what you are saying there is no way for compB to always use the class
>>> from CompA, when the flow is:
>>>
>>> CompA --> CompB --> CompC.
>>>
>>> Correct?
>>>
>>>
>>>
>> Yes, if instances from CompA flow through CompB to CompC then they must all
>> agree on the same version of CompA.
>>
>>
>> This issue may be because I use concrete files to test my case. In real
>>
>>> life
>>> the dependency will be to an interface in CompA. the difference between
>>> the
>>> version used by CompB and CompC will be only the implementation injected
>>> using Spring.
>>>
>>> I hope to fine that B works with it's own "known" implementation version
>>> even when invoked from C.
>>>
>>>
>>>
>> Well, technically it is possible, but it still depends. At a minimum, CompB
>> and CompC will have to have the interface type in common, otherwise it still
>> won't work.
>>
>> Assume we have some interface IFoo coming from BundleZ.
>>
>> Then assume we have FooImpl1 by BundleA and FooImpl2 by BundleB. Both of
>> these bundles import IFoo from BundleZ.
>>
>> Now I can have client BundleC that imports from BundleZ. This will works
>> with either implementation of IFoo because they all share a common type:
>> IFoo.
>>
>> Just keep in mind your original question above...if the types flow through
>> a bundle to client bundle bundles, then they must agree on the same version
>> of the type. If a type does not flow through a bundle, then its clients are
>> not constrained by the type.
>>
>> -> richard
>>
>>
>> I'll check it out next week.
>>
>>> Please advise if my above logic has a flaw.
>>>
>>> On Thu, Apr 15, 2010 at 7:49 PM, Richard S. Hall<heavy@ungoverned.org
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>
>>>> On 4/15/10 12:39, Richard S. Hall wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On 4/15/10 10:08, Yair Ogen wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I am not following. I always want CompB to use a fixed version of CompA
>>>>>> regardless of the calling API code.
>>>>>>
>>>>>> Is this possible? The direct dependency between CompC and CompA (newer
>>>>>> version) is a real situation.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Apparently, I am not explaining this in an understandable way, so maybe
>>>>> someone else can jump in and give it a try.
>>>>>
>>>>> The main issue has nothing to do with the dependencies of CompC->CompA
>>>>> or
>>>>> CompB->CompA...in isolation, CompC and CompB can have dependencies on
>>>>> any
>>>>> version of CompA they wish independently.
>>>>>
>>>>> The only issue is the dependency of CompC->CompB. This requires that the
>>>>> class spaces of the two bundles intersect via some common types. If
>>>>> those
>>>>> common types come from CompA, then you have a problem since CompC and
>>>>> CompB
>>>>> do not use a common version of CompA. If they do not include types from
>>>>> CompA, then it will work.
>>>>>
>>>>> In your case, since you are getting a "uses" constraint violation, it
>>>>> likely means your CompB component exposes CompA types to its importers,
>>>>> which means CompC can't use it. See the example I created before, does
>>>>> the
>>>>> exported package from CompB accept any CompA types as parameters or
>>>>> return
>>>>> any of those types from methods? If so, then CompC can't use it, since
>>>>> they
>>>>> don't agree on a common set of CompA types.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> To try to illustrate a working scenario, since that might be more
>>>> helpful,
>>>> assume CompB exports a package containing only a class like:
>>>>
>>>> public class CompB {
>>>> public String getName();
>>>> public CompB getChildComponent();
>>>> }
>>>>
>>>> Since none of these types come from CompA 1.0, then CompC could import
>>>> this
>>>> package, because the two versions of CompA would not conflict. Where as
>>>> something like this would not work:
>>>>
>>>> public class CompB {
>>>> public String getName();
>>>> public CompA getChildComponent();
>>>> }
>>>>
>>>> So, if any of the classes in the package exported by CompB (and imported
>>>> by
>>>> CompC) publicly expose a type from CompA, then you have an issue since
>>>> all
>>>> importers must use the same version of the type.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>> Please advise.
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> On 4/15/10 9:17, Yair Ogen wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thank you very much and yes this is exactly what I wanted to achieve,
>>>>>>> I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> know
>>>>>>>> regular Java does not allow this, however I thought that OSGi special
>>>>>>>> ClassLoader model resolves this issue.
>>>>>>>>
>>>>>>>> I think this is a real life scenario. for example, assume based on
>>>>>>>> my previously described Component Graph that the logic behind the
>>>>>>>> scenes
>>>>>>>> is
>>>>>>>> that CompB was tested with CompA a long time ago. Comp C uses Comp B
>>>>>>>> but
>>>>>>>> also uses new version of CompA since it is a newer component.
>>>>>>>>
>>>>>>>> It is a real requirement for me (I think this is common to all?) that
>>>>>>>> the
>>>>>>>> system engineers do not allow me to have B use the new CompA since
>>>>>>>> this
>>>>>>>> combination was never tested. They do not want to have full
>>>>>>>> regressions
>>>>>>>> tests either.
>>>>>>>>
>>>>>>>> So, the route CompC --> CompA should use newer version, but the
>>>>>>>> route
>>>>>>>> CompC
>>>>>>>> --> CompB --> CompA should use the older version.
>>>>>>>>
>>>>>>>> So, I need to tell them this is not possible?
>>>>>>>>
>>>>>>>>
>>>>>>>> To be clear, if CompC somehow gets objects from CompB that are
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> instances
>>>>>>> from classes from CompA, then it will not work. This is because CompC
>>>>>>> is
>>>>>>> expecting the CompA instances to be 1.0.1, but the instances that
>>>>>>> CompB
>>>>>>> returns are 1.0.0. A given class can only see one version of a type at
>>>>>>> a
>>>>>>> time.
>>>>>>>
>>>>>>> However, if CompB only uses class from CompA internally and never
>>>>>>> exposes
>>>>>>> them to CompC, then it is possible for both CompB and CompC to use
>>>>>>> different
>>>>>>> versions of that type.
>>>>>>>
>>>>>>> There is a slight variation where CompB might expose CompA types, but
>>>>>>> CompC
>>>>>>> doesn't actually ever use those types from CompB. In this case, you
>>>>>>> could
>>>>>>> technically cheat and modify your CompB bundle metadata so it doesn't
>>>>>>> report
>>>>>>> the "uses" constraints. But I wouldn't recommend this since it would
>>>>>>> be
>>>>>>> really fragile and would likely blow up in other situations where you
>>>>>>> reuse
>>>>>>> CompB.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Yair
>>>>>>>>
>>>>>>>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<
>>>>>>>> heavy@ungoverned.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As I mentioned in my original response, it is supported assuming B
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> doesn't
>>>>>>>>> expose A to C...it sounds like com.something.b.main exposes A v1 to
>>>>>>>>> C
>>>>>>>>> who
>>>>>>>>> is
>>>>>>>>> only allowed to see A v1.0.1.
>>>>>>>>>
>>>>>>>>> For example, assume B has a class like:
>>>>>>>>>
>>>>>>>>> public interface com.something.b.main.Foo {
>>>>>>>>> com.something.classes.Bar getBar();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Assuming com.something.classes.Bar comes from bundle A, then bundle
>>>>>>>>> C
>>>>>>>>> will
>>>>>>>>> not be allowed to use com.something.b.main, because it would cause
>>>>>>>>> it
>>>>>>>>> to
>>>>>>>>> see
>>>>>>>>> a different version of the package than what it is allowed to see.
>>>>>>>>> If
>>>>>>>>> this
>>>>>>>>> is specifically what you are trying to achieve, then you can't do
>>>>>>>>> this
>>>>>>>>> with
>>>>>>>>> Java at all. A given class can only see one version of another class
>>>>>>>>> at a
>>>>>>>>> time...otherwise you get class cast exceptions.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any help appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Yair
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<
>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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<
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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<
>>>>>>>>>>>>>> heavy@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<heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>> users-help@felix.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
I see you point.
Isn't this a common issue where you want to freeze an interface
implementation version? How can this be achieved?
Scenario where both CompB and CopmpC are clients of API in CompA - is common
enough.
Isn't a requirement that when CompC uses CompA directly it gets impl1 and
when CompB uses CompA it uses impl2 - regardless to the source of invocation
(CompC or any other component) also common?
On Sun, Apr 18, 2010 at 1:30 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 4/17/10 14:31, Yair Ogen wrote:
>
>> Well, htis might be it.
>>
>> CompB imports a class from CompA.
>>
>> So, what you are saying there is no way for compB to always use the class
>> from CompA, when the flow is:
>>
>> CompA --> CompB --> CompC.
>>
>> Correct?
>>
>>
>
> Yes, if instances from CompA flow through CompB to CompC then they must all
> agree on the same version of CompA.
>
>
> This issue may be because I use concrete files to test my case. In real
>> life
>> the dependency will be to an interface in CompA. the difference between
>> the
>> version used by CompB and CompC will be only the implementation injected
>> using Spring.
>>
>> I hope to fine that B works with it's own "known" implementation version
>> even when invoked from C.
>>
>>
>
> Well, technically it is possible, but it still depends. At a minimum, CompB
> and CompC will have to have the interface type in common, otherwise it still
> won't work.
>
> Assume we have some interface IFoo coming from BundleZ.
>
> Then assume we have FooImpl1 by BundleA and FooImpl2 by BundleB. Both of
> these bundles import IFoo from BundleZ.
>
> Now I can have client BundleC that imports from BundleZ. This will works
> with either implementation of IFoo because they all share a common type:
> IFoo.
>
> Just keep in mind your original question above...if the types flow through
> a bundle to client bundle bundles, then they must agree on the same version
> of the type. If a type does not flow through a bundle, then its clients are
> not constrained by the type.
>
> -> richard
>
>
> I'll check it out next week.
>>
>> Please advise if my above logic has a flaw.
>>
>> On Thu, Apr 15, 2010 at 7:49 PM, Richard S. Hall<heavy@ungoverned.org
>> >wrote:
>>
>>
>>
>>> On 4/15/10 12:39, Richard S. Hall wrote:
>>>
>>>
>>>
>>>> On 4/15/10 10:08, Yair Ogen wrote:
>>>>
>>>>
>>>>
>>>>> I am not following. I always want CompB to use a fixed version of CompA
>>>>> regardless of the calling API code.
>>>>>
>>>>> Is this possible? The direct dependency between CompC and CompA (newer
>>>>> version) is a real situation.
>>>>>
>>>>>
>>>>>
>>>> Apparently, I am not explaining this in an understandable way, so maybe
>>>> someone else can jump in and give it a try.
>>>>
>>>> The main issue has nothing to do with the dependencies of CompC->CompA
>>>> or
>>>> CompB->CompA...in isolation, CompC and CompB can have dependencies on
>>>> any
>>>> version of CompA they wish independently.
>>>>
>>>> The only issue is the dependency of CompC->CompB. This requires that the
>>>> class spaces of the two bundles intersect via some common types. If
>>>> those
>>>> common types come from CompA, then you have a problem since CompC and
>>>> CompB
>>>> do not use a common version of CompA. If they do not include types from
>>>> CompA, then it will work.
>>>>
>>>> In your case, since you are getting a "uses" constraint violation, it
>>>> likely means your CompB component exposes CompA types to its importers,
>>>> which means CompC can't use it. See the example I created before, does
>>>> the
>>>> exported package from CompB accept any CompA types as parameters or
>>>> return
>>>> any of those types from methods? If so, then CompC can't use it, since
>>>> they
>>>> don't agree on a common set of CompA types.
>>>>
>>>>
>>>>
>>> To try to illustrate a working scenario, since that might be more
>>> helpful,
>>> assume CompB exports a package containing only a class like:
>>>
>>> public class CompB {
>>> public String getName();
>>> public CompB getChildComponent();
>>> }
>>>
>>> Since none of these types come from CompA 1.0, then CompC could import
>>> this
>>> package, because the two versions of CompA would not conflict. Where as
>>> something like this would not work:
>>>
>>> public class CompB {
>>> public String getName();
>>> public CompA getChildComponent();
>>> }
>>>
>>> So, if any of the classes in the package exported by CompB (and imported
>>> by
>>> CompC) publicly expose a type from CompA, then you have an issue since
>>> all
>>> importers must use the same version of the type.
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>> Please advise.
>>>>
>>>>
>>>>> On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>> On 4/15/10 9:17, Yair Ogen wrote:
>>>>>
>>>>>
>>>>>> Thank you very much and yes this is exactly what I wanted to achieve,
>>>>>> I
>>>>>>
>>>>>>
>>>>>>> know
>>>>>>> regular Java does not allow this, however I thought that OSGi special
>>>>>>> ClassLoader model resolves this issue.
>>>>>>>
>>>>>>> I think this is a real life scenario. for example, assume based on
>>>>>>> my previously described Component Graph that the logic behind the
>>>>>>> scenes
>>>>>>> is
>>>>>>> that CompB was tested with CompA a long time ago. Comp C uses Comp B
>>>>>>> but
>>>>>>> also uses new version of CompA since it is a newer component.
>>>>>>>
>>>>>>> It is a real requirement for me (I think this is common to all?) that
>>>>>>> the
>>>>>>> system engineers do not allow me to have B use the new CompA since
>>>>>>> this
>>>>>>> combination was never tested. They do not want to have full
>>>>>>> regressions
>>>>>>> tests either.
>>>>>>>
>>>>>>> So, the route CompC --> CompA should use newer version, but the
>>>>>>> route
>>>>>>> CompC
>>>>>>> --> CompB --> CompA should use the older version.
>>>>>>>
>>>>>>> So, I need to tell them this is not possible?
>>>>>>>
>>>>>>>
>>>>>>> To be clear, if CompC somehow gets objects from CompB that are
>>>>>>>
>>>>>>>
>>>>>> instances
>>>>>> from classes from CompA, then it will not work. This is because CompC
>>>>>> is
>>>>>> expecting the CompA instances to be 1.0.1, but the instances that
>>>>>> CompB
>>>>>> returns are 1.0.0. A given class can only see one version of a type at
>>>>>> a
>>>>>> time.
>>>>>>
>>>>>> However, if CompB only uses class from CompA internally and never
>>>>>> exposes
>>>>>> them to CompC, then it is possible for both CompB and CompC to use
>>>>>> different
>>>>>> versions of that type.
>>>>>>
>>>>>> There is a slight variation where CompB might expose CompA types, but
>>>>>> CompC
>>>>>> doesn't actually ever use those types from CompB. In this case, you
>>>>>> could
>>>>>> technically cheat and modify your CompB bundle metadata so it doesn't
>>>>>> report
>>>>>> the "uses" constraints. But I wouldn't recommend this since it would
>>>>>> be
>>>>>> really fragile and would likely blow up in other situations where you
>>>>>> reuse
>>>>>> CompB.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Yair
>>>>>>>
>>>>>>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<
>>>>>>> heavy@ungoverned.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As I mentioned in my original response, it is supported assuming B
>>>>>>>>>
>>>>>>>>>
>>>>>>>> doesn't
>>>>>>>> expose A to C...it sounds like com.something.b.main exposes A v1 to
>>>>>>>> C
>>>>>>>> who
>>>>>>>> is
>>>>>>>> only allowed to see A v1.0.1.
>>>>>>>>
>>>>>>>> For example, assume B has a class like:
>>>>>>>>
>>>>>>>> public interface com.something.b.main.Foo {
>>>>>>>> com.something.classes.Bar getBar();
>>>>>>>> }
>>>>>>>>
>>>>>>>> Assuming com.something.classes.Bar comes from bundle A, then bundle
>>>>>>>> C
>>>>>>>> will
>>>>>>>> not be allowed to use com.something.b.main, because it would cause
>>>>>>>> it
>>>>>>>> to
>>>>>>>> see
>>>>>>>> a different version of the package than what it is allowed to see.
>>>>>>>> If
>>>>>>>> this
>>>>>>>> is specifically what you are trying to achieve, then you can't do
>>>>>>>> this
>>>>>>>> with
>>>>>>>> Java at all. A given class can only see one version of another class
>>>>>>>> at a
>>>>>>>> time...otherwise you get class cast exceptions.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>
>>>>>>>> Any help appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>
>>>>>>>>> Yair
>>>>>>>>>
>>>>>>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<
>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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<
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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<
>>>>>>>>>>>>> heavy@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<heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>> users-help@felix.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/17/10 14:31, Yair Ogen wrote:
> Well, htis might be it.
>
> CompB imports a class from CompA.
>
> So, what you are saying there is no way for compB to always use the class
> from CompA, when the flow is:
>
> CompA --> CompB --> CompC.
>
> Correct?
>
Yes, if instances from CompA flow through CompB to CompC then they must
all agree on the same version of CompA.
> This issue may be because I use concrete files to test my case. In real life
> the dependency will be to an interface in CompA. the difference between the
> version used by CompB and CompC will be only the implementation injected
> using Spring.
>
> I hope to fine that B works with it's own "known" implementation version
> even when invoked from C.
>
Well, technically it is possible, but it still depends. At a minimum,
CompB and CompC will have to have the interface type in common,
otherwise it still won't work.
Assume we have some interface IFoo coming from BundleZ.
Then assume we have FooImpl1 by BundleA and FooImpl2 by BundleB. Both of
these bundles import IFoo from BundleZ.
Now I can have client BundleC that imports from BundleZ. This will works
with either implementation of IFoo because they all share a common type:
IFoo.
Just keep in mind your original question above...if the types flow
through a bundle to client bundle bundles, then they must agree on the
same version of the type. If a type does not flow through a bundle, then
its clients are not constrained by the type.
-> richard
> I'll check it out next week.
>
> Please advise if my above logic has a flaw.
>
> On Thu, Apr 15, 2010 at 7:49 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 4/15/10 12:39, Richard S. Hall wrote:
>>
>>
>>> On 4/15/10 10:08, Yair Ogen wrote:
>>>
>>>
>>>> I am not following. I always want CompB to use a fixed version of CompA
>>>> regardless of the calling API code.
>>>>
>>>> Is this possible? The direct dependency between CompC and CompA (newer
>>>> version) is a real situation.
>>>>
>>>>
>>> Apparently, I am not explaining this in an understandable way, so maybe
>>> someone else can jump in and give it a try.
>>>
>>> The main issue has nothing to do with the dependencies of CompC->CompA or
>>> CompB->CompA...in isolation, CompC and CompB can have dependencies on any
>>> version of CompA they wish independently.
>>>
>>> The only issue is the dependency of CompC->CompB. This requires that the
>>> class spaces of the two bundles intersect via some common types. If those
>>> common types come from CompA, then you have a problem since CompC and CompB
>>> do not use a common version of CompA. If they do not include types from
>>> CompA, then it will work.
>>>
>>> In your case, since you are getting a "uses" constraint violation, it
>>> likely means your CompB component exposes CompA types to its importers,
>>> which means CompC can't use it. See the example I created before, does the
>>> exported package from CompB accept any CompA types as parameters or return
>>> any of those types from methods? If so, then CompC can't use it, since they
>>> don't agree on a common set of CompA types.
>>>
>>>
>> To try to illustrate a working scenario, since that might be more helpful,
>> assume CompB exports a package containing only a class like:
>>
>> public class CompB {
>> public String getName();
>> public CompB getChildComponent();
>> }
>>
>> Since none of these types come from CompA 1.0, then CompC could import this
>> package, because the two versions of CompA would not conflict. Where as
>> something like this would not work:
>>
>> public class CompB {
>> public String getName();
>> public CompA getChildComponent();
>> }
>>
>> So, if any of the classes in the package exported by CompB (and imported by
>> CompC) publicly expose a type from CompA, then you have an issue since all
>> importers must use the same version of the type.
>>
>> -> richard
>>
>>
>>
>>
>>> -> richard
>>>
>>>
>>>
>>> Please advise.
>>>
>>>> On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall<heavy@ungoverned.org
>>>>
>>>>> wrote:
>>>>>
>>>> On 4/15/10 9:17, Yair Ogen wrote:
>>>>
>>>>> Thank you very much and yes this is exactly what I wanted to achieve, I
>>>>>
>>>>>> know
>>>>>> regular Java does not allow this, however I thought that OSGi special
>>>>>> ClassLoader model resolves this issue.
>>>>>>
>>>>>> I think this is a real life scenario. for example, assume based on
>>>>>> my previously described Component Graph that the logic behind the
>>>>>> scenes
>>>>>> is
>>>>>> that CompB was tested with CompA a long time ago. Comp C uses Comp B
>>>>>> but
>>>>>> also uses new version of CompA since it is a newer component.
>>>>>>
>>>>>> It is a real requirement for me (I think this is common to all?) that
>>>>>> the
>>>>>> system engineers do not allow me to have B use the new CompA since this
>>>>>> combination was never tested. They do not want to have full regressions
>>>>>> tests either.
>>>>>>
>>>>>> So, the route CompC --> CompA should use newer version, but the route
>>>>>> CompC
>>>>>> --> CompB --> CompA should use the older version.
>>>>>>
>>>>>> So, I need to tell them this is not possible?
>>>>>>
>>>>>>
>>>>>> To be clear, if CompC somehow gets objects from CompB that are
>>>>>>
>>>>> instances
>>>>> from classes from CompA, then it will not work. This is because CompC is
>>>>> expecting the CompA instances to be 1.0.1, but the instances that CompB
>>>>> returns are 1.0.0. A given class can only see one version of a type at a
>>>>> time.
>>>>>
>>>>> However, if CompB only uses class from CompA internally and never
>>>>> exposes
>>>>> them to CompC, then it is possible for both CompB and CompC to use
>>>>> different
>>>>> versions of that type.
>>>>>
>>>>> There is a slight variation where CompB might expose CompA types, but
>>>>> CompC
>>>>> doesn't actually ever use those types from CompB. In this case, you
>>>>> could
>>>>> technically cheat and modify your CompB bundle metadata so it doesn't
>>>>> report
>>>>> the "uses" constraints. But I wouldn't recommend this since it would be
>>>>> really fragile and would likely blow up in other situations where you
>>>>> reuse
>>>>> CompB.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>> Yair
>>>>>>
>>>>>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As I mentioned in my original response, it is supported assuming B
>>>>>>>>
>>>>>>> doesn't
>>>>>>> expose A to C...it sounds like com.something.b.main exposes A v1 to C
>>>>>>> who
>>>>>>> is
>>>>>>> only allowed to see A v1.0.1.
>>>>>>>
>>>>>>> For example, assume B has a class like:
>>>>>>>
>>>>>>> public interface com.something.b.main.Foo {
>>>>>>> com.something.classes.Bar getBar();
>>>>>>> }
>>>>>>>
>>>>>>> Assuming com.something.classes.Bar comes from bundle A, then bundle C
>>>>>>> will
>>>>>>> not be allowed to use com.something.b.main, because it would cause it
>>>>>>> to
>>>>>>> see
>>>>>>> a different version of the package than what it is allowed to see. If
>>>>>>> this
>>>>>>> is specifically what you are trying to achieve, then you can't do this
>>>>>>> with
>>>>>>> Java at all. A given class can only see one version of another class
>>>>>>> at a
>>>>>>> time...otherwise you get class cast exceptions.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>
>>>>>>> Any help appreciated.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>> Yair
>>>>>>>>
>>>>>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<
>>>>>>>> heavy@ungoverned.org
>>>>>>>>
>>>>>>>>
>>>>>>>> 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<
>>>>>>>>>
>>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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<
>>>>>>>>>>>> heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
Well, htis might be it.
CompB imports a class from CompA.
So, what you are saying there is no way for compB to always use the class
from CompA, when the flow is:
CompA --> CompB --> CompC.
Correct?
This issue may be because I use concrete files to test my case. In real life
the dependency will be to an interface in CompA. the difference between the
version used by CompB and CompC will be only the implementation injected
using Spring.
I hope to fine that B works with it's own "known" implementation version
even when invoked from C.
I'll check it out next week.
Please advise if my above logic has a flaw.
On Thu, Apr 15, 2010 at 7:49 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 4/15/10 12:39, Richard S. Hall wrote:
>
>> On 4/15/10 10:08, Yair Ogen wrote:
>>
>>> I am not following. I always want CompB to use a fixed version of CompA
>>> regardless of the calling API code.
>>>
>>> Is this possible? The direct dependency between CompC and CompA (newer
>>> version) is a real situation.
>>>
>>
>> Apparently, I am not explaining this in an understandable way, so maybe
>> someone else can jump in and give it a try.
>>
>> The main issue has nothing to do with the dependencies of CompC->CompA or
>> CompB->CompA...in isolation, CompC and CompB can have dependencies on any
>> version of CompA they wish independently.
>>
>> The only issue is the dependency of CompC->CompB. This requires that the
>> class spaces of the two bundles intersect via some common types. If those
>> common types come from CompA, then you have a problem since CompC and CompB
>> do not use a common version of CompA. If they do not include types from
>> CompA, then it will work.
>>
>> In your case, since you are getting a "uses" constraint violation, it
>> likely means your CompB component exposes CompA types to its importers,
>> which means CompC can't use it. See the example I created before, does the
>> exported package from CompB accept any CompA types as parameters or return
>> any of those types from methods? If so, then CompC can't use it, since they
>> don't agree on a common set of CompA types.
>>
>
> To try to illustrate a working scenario, since that might be more helpful,
> assume CompB exports a package containing only a class like:
>
> public class CompB {
> public String getName();
> public CompB getChildComponent();
> }
>
> Since none of these types come from CompA 1.0, then CompC could import this
> package, because the two versions of CompA would not conflict. Where as
> something like this would not work:
>
> public class CompB {
> public String getName();
> public CompA getChildComponent();
> }
>
> So, if any of the classes in the package exported by CompB (and imported by
> CompC) publicly expose a type from CompA, then you have an issue since all
> importers must use the same version of the type.
>
> -> richard
>
>
>
>> -> richard
>>
>>
>>
>> Please advise.
>>>
>>> On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall<heavy@ungoverned.org
>>> >wrote:
>>>
>>> On 4/15/10 9:17, Yair Ogen wrote:
>>>>
>>>> Thank you very much and yes this is exactly what I wanted to achieve, I
>>>>> know
>>>>> regular Java does not allow this, however I thought that OSGi special
>>>>> ClassLoader model resolves this issue.
>>>>>
>>>>> I think this is a real life scenario. for example, assume based on
>>>>> my previously described Component Graph that the logic behind the
>>>>> scenes
>>>>> is
>>>>> that CompB was tested with CompA a long time ago. Comp C uses Comp B
>>>>> but
>>>>> also uses new version of CompA since it is a newer component.
>>>>>
>>>>> It is a real requirement for me (I think this is common to all?) that
>>>>> the
>>>>> system engineers do not allow me to have B use the new CompA since this
>>>>> combination was never tested. They do not want to have full regressions
>>>>> tests either.
>>>>>
>>>>> So, the route CompC --> CompA should use newer version, but the route
>>>>> CompC
>>>>> --> CompB --> CompA should use the older version.
>>>>>
>>>>> So, I need to tell them this is not possible?
>>>>>
>>>>>
>>>>> To be clear, if CompC somehow gets objects from CompB that are
>>>> instances
>>>> from classes from CompA, then it will not work. This is because CompC is
>>>> expecting the CompA instances to be 1.0.1, but the instances that CompB
>>>> returns are 1.0.0. A given class can only see one version of a type at a
>>>> time.
>>>>
>>>> However, if CompB only uses class from CompA internally and never
>>>> exposes
>>>> them to CompC, then it is possible for both CompB and CompC to use
>>>> different
>>>> versions of that type.
>>>>
>>>> There is a slight variation where CompB might expose CompA types, but
>>>> CompC
>>>> doesn't actually ever use those types from CompB. In this case, you
>>>> could
>>>> technically cheat and modify your CompB bundle metadata so it doesn't
>>>> report
>>>> the "uses" constraints. But I wouldn't recommend this since it would be
>>>> really fragile and would likely blow up in other situations where you
>>>> reuse
>>>> CompB.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> Regards,
>>>>
>>>>> Yair
>>>>>
>>>>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>>
>>>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As I mentioned in my original response, it is supported assuming B
>>>>>> doesn't
>>>>>> expose A to C...it sounds like com.something.b.main exposes A v1 to C
>>>>>> who
>>>>>> is
>>>>>> only allowed to see A v1.0.1.
>>>>>>
>>>>>> For example, assume B has a class like:
>>>>>>
>>>>>> public interface com.something.b.main.Foo {
>>>>>> com.something.classes.Bar getBar();
>>>>>> }
>>>>>>
>>>>>> Assuming com.something.classes.Bar comes from bundle A, then bundle C
>>>>>> will
>>>>>> not be allowed to use com.something.b.main, because it would cause it
>>>>>> to
>>>>>> see
>>>>>> a different version of the package than what it is allowed to see. If
>>>>>> this
>>>>>> is specifically what you are trying to achieve, then you can't do this
>>>>>> with
>>>>>> Java at all. A given class can only see one version of another class
>>>>>> at a
>>>>>> time...otherwise you get class cast exceptions.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> Any help appreciated.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>>
>>>>>>> Yair
>>>>>>>
>>>>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<
>>>>>>> heavy@ungoverned.org
>>>>>>>
>>>>>>>
>>>>>>> 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<
>>>>>>>>> heavy@ungoverned.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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<
>>>>>>>>>>> heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/15/10 12:39, Richard S. Hall wrote:
> On 4/15/10 10:08, Yair Ogen wrote:
>> I am not following. I always want CompB to use a fixed version of CompA
>> regardless of the calling API code.
>>
>> Is this possible? The direct dependency between CompC and CompA (newer
>> version) is a real situation.
>
> Apparently, I am not explaining this in an understandable way, so
> maybe someone else can jump in and give it a try.
>
> The main issue has nothing to do with the dependencies of CompC->CompA
> or CompB->CompA...in isolation, CompC and CompB can have dependencies
> on any version of CompA they wish independently.
>
> The only issue is the dependency of CompC->CompB. This requires that
> the class spaces of the two bundles intersect via some common types.
> If those common types come from CompA, then you have a problem since
> CompC and CompB do not use a common version of CompA. If they do not
> include types from CompA, then it will work.
>
> In your case, since you are getting a "uses" constraint violation, it
> likely means your CompB component exposes CompA types to its
> importers, which means CompC can't use it. See the example I created
> before, does the exported package from CompB accept any CompA types as
> parameters or return any of those types from methods? If so, then
> CompC can't use it, since they don't agree on a common set of CompA
> types.
To try to illustrate a working scenario, since that might be more
helpful, assume CompB exports a package containing only a class like:
public class CompB {
public String getName();
public CompB getChildComponent();
}
Since none of these types come from CompA 1.0, then CompC could import
this package, because the two versions of CompA would not conflict.
Where as something like this would not work:
public class CompB {
public String getName();
public CompA getChildComponent();
}
So, if any of the classes in the package exported by CompB (and imported
by CompC) publicly expose a type from CompA, then you have an issue
since all importers must use the same version of the type.
-> richard
>
> -> richard
>
>
>
>> Please advise.
>>
>> On Thu, Apr 15, 2010 at 4:46 PM, Richard S.
>> Hall<he...@ungoverned.org>wrote:
>>
>>> On 4/15/10 9:17, Yair Ogen wrote:
>>>
>>>> Thank you very much and yes this is exactly what I wanted to
>>>> achieve, I
>>>> know
>>>> regular Java does not allow this, however I thought that OSGi special
>>>> ClassLoader model resolves this issue.
>>>>
>>>> I think this is a real life scenario. for example, assume based on
>>>> my previously described Component Graph that the logic behind the
>>>> scenes
>>>> is
>>>> that CompB was tested with CompA a long time ago. Comp C uses Comp
>>>> B but
>>>> also uses new version of CompA since it is a newer component.
>>>>
>>>> It is a real requirement for me (I think this is common to all?)
>>>> that the
>>>> system engineers do not allow me to have B use the new CompA since
>>>> this
>>>> combination was never tested. They do not want to have full
>>>> regressions
>>>> tests either.
>>>>
>>>> So, the route CompC --> CompA should use newer version, but the
>>>> route
>>>> CompC
>>>> --> CompB --> CompA should use the older version.
>>>>
>>>> So, I need to tell them this is not possible?
>>>>
>>>>
>>> To be clear, if CompC somehow gets objects from CompB that are
>>> instances
>>> from classes from CompA, then it will not work. This is because
>>> CompC is
>>> expecting the CompA instances to be 1.0.1, but the instances that CompB
>>> returns are 1.0.0. A given class can only see one version of a type
>>> at a
>>> time.
>>>
>>> However, if CompB only uses class from CompA internally and never
>>> exposes
>>> them to CompC, then it is possible for both CompB and CompC to use
>>> different
>>> versions of that type.
>>>
>>> There is a slight variation where CompB might expose CompA types,
>>> but CompC
>>> doesn't actually ever use those types from CompB. In this case, you
>>> could
>>> technically cheat and modify your CompB bundle metadata so it
>>> doesn't report
>>> the "uses" constraints. But I wouldn't recommend this since it would be
>>> really fragile and would likely blow up in other situations where
>>> you reuse
>>> CompB.
>>>
>>> -> richard
>>>
>>>
>>> Regards,
>>>> Yair
>>>>
>>>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<heavy@ungoverned.org
>>>>> wrote:
>>>>
>>>>
>>>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> As I mentioned in my original response, it is supported assuming B
>>>>> doesn't
>>>>> expose A to C...it sounds like com.something.b.main exposes A v1
>>>>> to C who
>>>>> is
>>>>> only allowed to see A v1.0.1.
>>>>>
>>>>> For example, assume B has a class like:
>>>>>
>>>>> public interface com.something.b.main.Foo {
>>>>> com.something.classes.Bar getBar();
>>>>> }
>>>>>
>>>>> Assuming com.something.classes.Bar comes from bundle A, then bundle C
>>>>> will
>>>>> not be allowed to use com.something.b.main, because it would cause
>>>>> it to
>>>>> see
>>>>> a different version of the package than what it is allowed to see. If
>>>>> this
>>>>> is specifically what you are trying to achieve, then you can't do
>>>>> this
>>>>> with
>>>>> Java at all. A given class can only see one version of another
>>>>> class at a
>>>>> time...otherwise you get class cast exceptions.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>> Any help appreciated.
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yair
>>>>>>
>>>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S.
>>>>>> Hall<heavy@ungoverned.org
>>>>>>
>>>>>>
>>>>>>> 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<heavy@ungoverned.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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<
>>>>>>>>>> heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/15/10 10:08, Yair Ogen wrote:
> I am not following. I always want CompB to use a fixed version of CompA
> regardless of the calling API code.
>
> Is this possible? The direct dependency between CompC and CompA (newer
> version) is a real situation.
>
Apparently, I am not explaining this in an understandable way, so maybe
someone else can jump in and give it a try.
The main issue has nothing to do with the dependencies of CompC->CompA
or CompB->CompA...in isolation, CompC and CompB can have dependencies on
any version of CompA they wish independently.
The only issue is the dependency of CompC->CompB. This requires that the
class spaces of the two bundles intersect via some common types. If
those common types come from CompA, then you have a problem since CompC
and CompB do not use a common version of CompA. If they do not include
types from CompA, then it will work.
In your case, since you are getting a "uses" constraint violation, it
likely means your CompB component exposes CompA types to its importers,
which means CompC can't use it. See the example I created before, does
the exported package from CompB accept any CompA types as parameters or
return any of those types from methods? If so, then CompC can't use it,
since they don't agree on a common set of CompA types.
-> richard
> Please advise.
>
> On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 4/15/10 9:17, Yair Ogen wrote:
>>
>>
>>> Thank you very much and yes this is exactly what I wanted to achieve, I
>>> know
>>> regular Java does not allow this, however I thought that OSGi special
>>> ClassLoader model resolves this issue.
>>>
>>> I think this is a real life scenario. for example, assume based on
>>> my previously described Component Graph that the logic behind the scenes
>>> is
>>> that CompB was tested with CompA a long time ago. Comp C uses Comp B but
>>> also uses new version of CompA since it is a newer component.
>>>
>>> It is a real requirement for me (I think this is common to all?) that the
>>> system engineers do not allow me to have B use the new CompA since this
>>> combination was never tested. They do not want to have full regressions
>>> tests either.
>>>
>>> So, the route CompC --> CompA should use newer version, but the route
>>> CompC
>>> --> CompB --> CompA should use the older version.
>>>
>>> So, I need to tell them this is not possible?
>>>
>>>
>>>
>> To be clear, if CompC somehow gets objects from CompB that are instances
>> from classes from CompA, then it will not work. This is because CompC is
>> expecting the CompA instances to be 1.0.1, but the instances that CompB
>> returns are 1.0.0. A given class can only see one version of a type at a
>> time.
>>
>> However, if CompB only uses class from CompA internally and never exposes
>> them to CompC, then it is possible for both CompB and CompC to use different
>> versions of that type.
>>
>> There is a slight variation where CompB might expose CompA types, but CompC
>> doesn't actually ever use those types from CompB. In this case, you could
>> technically cheat and modify your CompB bundle metadata so it doesn't report
>> the "uses" constraints. But I wouldn't recommend this since it would be
>> really fragile and would likely blow up in other situations where you reuse
>> CompB.
>>
>> -> richard
>>
>>
>> Regards,
>>
>>> Yair
>>>
>>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<heavy@ungoverned.org
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>
>>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> 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?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> As I mentioned in my original response, it is supported assuming B
>>>> doesn't
>>>> expose A to C...it sounds like com.something.b.main exposes A v1 to C who
>>>> is
>>>> only allowed to see A v1.0.1.
>>>>
>>>> For example, assume B has a class like:
>>>>
>>>> public interface com.something.b.main.Foo {
>>>> com.something.classes.Bar getBar();
>>>> }
>>>>
>>>> Assuming com.something.classes.Bar comes from bundle A, then bundle C
>>>> will
>>>> not be allowed to use com.something.b.main, because it would cause it to
>>>> see
>>>> a different version of the package than what it is allowed to see. If
>>>> this
>>>> is specifically what you are trying to achieve, then you can't do this
>>>> with
>>>> Java at all. A given class can only see one version of another class at a
>>>> time...otherwise you get class cast exceptions.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> Any help appreciated.
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Yair
>>>>>
>>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<heavy@ungoverned.org
>>>>>
>>>>>
>>>>>
>>>>>> 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<heavy@ungoverned.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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<
>>>>>>>>> heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
I am not following. I always want CompB to use a fixed version of CompA
regardless of the calling API code.
Is this possible? The direct dependency between CompC and CompA (newer
version) is a real situation.
Please advise.
On Thu, Apr 15, 2010 at 4:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 4/15/10 9:17, Yair Ogen wrote:
>
>> Thank you very much and yes this is exactly what I wanted to achieve, I
>> know
>> regular Java does not allow this, however I thought that OSGi special
>> ClassLoader model resolves this issue.
>>
>> I think this is a real life scenario. for example, assume based on
>> my previously described Component Graph that the logic behind the scenes
>> is
>> that CompB was tested with CompA a long time ago. Comp C uses Comp B but
>> also uses new version of CompA since it is a newer component.
>>
>> It is a real requirement for me (I think this is common to all?) that the
>> system engineers do not allow me to have B use the new CompA since this
>> combination was never tested. They do not want to have full regressions
>> tests either.
>>
>> So, the route CompC --> CompA should use newer version, but the route
>> CompC
>> --> CompB --> CompA should use the older version.
>>
>> So, I need to tell them this is not possible?
>>
>>
>
> To be clear, if CompC somehow gets objects from CompB that are instances
> from classes from CompA, then it will not work. This is because CompC is
> expecting the CompA instances to be 1.0.1, but the instances that CompB
> returns are 1.0.0. A given class can only see one version of a type at a
> time.
>
> However, if CompB only uses class from CompA internally and never exposes
> them to CompC, then it is possible for both CompB and CompC to use different
> versions of that type.
>
> There is a slight variation where CompB might expose CompA types, but CompC
> doesn't actually ever use those types from CompB. In this case, you could
> technically cheat and modify your CompB bundle metadata so it doesn't report
> the "uses" constraints. But I wouldn't recommend this since it would be
> really fragile and would likely blow up in other situations where you reuse
> CompB.
>
> -> richard
>
>
> Regards,
>>
>> Yair
>>
>> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<heavy@ungoverned.org
>> >wrote:
>>
>>
>>
>>> On 4/15/10 2:17, Yair Ogen wrote:
>>>
>>>
>>>
>>>> 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?
>>>>
>>>>
>>>>
>>>>
>>> As I mentioned in my original response, it is supported assuming B
>>> doesn't
>>> expose A to C...it sounds like com.something.b.main exposes A v1 to C who
>>> is
>>> only allowed to see A v1.0.1.
>>>
>>> For example, assume B has a class like:
>>>
>>> public interface com.something.b.main.Foo {
>>> com.something.classes.Bar getBar();
>>> }
>>>
>>> Assuming com.something.classes.Bar comes from bundle A, then bundle C
>>> will
>>> not be allowed to use com.something.b.main, because it would cause it to
>>> see
>>> a different version of the package than what it is allowed to see. If
>>> this
>>> is specifically what you are trying to achieve, then you can't do this
>>> with
>>> Java at all. A given class can only see one version of another class at a
>>> time...otherwise you get class cast exceptions.
>>>
>>> -> richard
>>>
>>>
>>> Any help appreciated.
>>>
>>>
>>>> Thanks,
>>>>
>>>> Yair
>>>>
>>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<heavy@ungoverned.org
>>>>
>>>>
>>>>> 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<heavy@ungoverned.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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<
>>>>>>>> heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/15/10 9:17, Yair Ogen wrote:
> Thank you very much and yes this is exactly what I wanted to achieve, I know
> regular Java does not allow this, however I thought that OSGi special
> ClassLoader model resolves this issue.
>
> I think this is a real life scenario. for example, assume based on
> my previously described Component Graph that the logic behind the scenes is
> that CompB was tested with CompA a long time ago. Comp C uses Comp B but
> also uses new version of CompA since it is a newer component.
>
> It is a real requirement for me (I think this is common to all?) that the
> system engineers do not allow me to have B use the new CompA since this
> combination was never tested. They do not want to have full regressions
> tests either.
>
> So, the route CompC --> CompA should use newer version, but the route CompC
> --> CompB --> CompA should use the older version.
>
> So, I need to tell them this is not possible?
>
To be clear, if CompC somehow gets objects from CompB that are instances
from classes from CompA, then it will not work. This is because CompC is
expecting the CompA instances to be 1.0.1, but the instances that CompB
returns are 1.0.0. A given class can only see one version of a type at a
time.
However, if CompB only uses class from CompA internally and never
exposes them to CompC, then it is possible for both CompB and CompC to
use different versions of that type.
There is a slight variation where CompB might expose CompA types, but
CompC doesn't actually ever use those types from CompB. In this case,
you could technically cheat and modify your CompB bundle metadata so it
doesn't report the "uses" constraints. But I wouldn't recommend this
since it would be really fragile and would likely blow up in other
situations where you reuse CompB.
-> richard
> Regards,
>
> Yair
>
> On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 4/15/10 2:17, Yair Ogen wrote:
>>
>>
>>> 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?
>>>
>>>
>>>
>> As I mentioned in my original response, it is supported assuming B doesn't
>> expose A to C...it sounds like com.something.b.main exposes A v1 to C who is
>> only allowed to see A v1.0.1.
>>
>> For example, assume B has a class like:
>>
>> public interface com.something.b.main.Foo {
>> com.something.classes.Bar getBar();
>> }
>>
>> Assuming com.something.classes.Bar comes from bundle A, then bundle C will
>> not be allowed to use com.something.b.main, because it would cause it to see
>> a different version of the package than what it is allowed to see. If this
>> is specifically what you are trying to achieve, then you can't do this with
>> Java at all. A given class can only see one version of another class at a
>> time...otherwise you get class cast exceptions.
>>
>> -> richard
>>
>>
>> Any help appreciated.
>>
>>> Thanks,
>>>
>>> Yair
>>>
>>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<heavy@ungoverned.org
>>>
>>>> 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<heavy@ungoverned.org
>>>>>
>>>>>
>>>>>
>>>>>> 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<heavy@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-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
Thank you very much and yes this is exactly what I wanted to achieve, I know
regular Java does not allow this, however I thought that OSGi special
ClassLoader model resolves this issue.
I think this is a real life scenario. for example, assume based on
my previously described Component Graph that the logic behind the scenes is
that CompB was tested with CompA a long time ago. Comp C uses Comp B but
also uses new version of CompA since it is a newer component.
It is a real requirement for me (I think this is common to all?) that the
system engineers do not allow me to have B use the new CompA since this
combination was never tested. They do not want to have full regressions
tests either.
So, the route CompC --> CompA should use newer version, but the route CompC
--> CompB --> CompA should use the older version.
So, I need to tell them this is not possible?
Regards,
Yair
On Thu, Apr 15, 2010 at 4:03 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 4/15/10 2:17, Yair Ogen wrote:
>
>> 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?
>>
>>
>
> As I mentioned in my original response, it is supported assuming B doesn't
> expose A to C...it sounds like com.something.b.main exposes A v1 to C who is
> only allowed to see A v1.0.1.
>
> For example, assume B has a class like:
>
> public interface com.something.b.main.Foo {
> com.something.classes.Bar getBar();
> }
>
> Assuming com.something.classes.Bar comes from bundle A, then bundle C will
> not be allowed to use com.something.b.main, because it would cause it to see
> a different version of the package than what it is allowed to see. If this
> is specifically what you are trying to achieve, then you can't do this with
> Java at all. A given class can only see one version of another class at a
> time...otherwise you get class cast exceptions.
>
> -> richard
>
>
> Any help appreciated.
>>
>> Thanks,
>>
>> Yair
>>
>> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<heavy@ungoverned.org
>> >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<heavy@ungoverned.org
>>>>
>>>>
>>>>> 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<heavy@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-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/15/10 2:17, Yair Ogen wrote:
> 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?
>
As I mentioned in my original response, it is supported assuming B
doesn't expose A to C...it sounds like com.something.b.main exposes A v1
to C who is only allowed to see A v1.0.1.
For example, assume B has a class like:
public interface com.something.b.main.Foo {
com.something.classes.Bar getBar();
}
Assuming com.something.classes.Bar comes from bundle A, then bundle C
will not be allowed to use com.something.b.main, because it would cause
it to see a different version of the package than what it is allowed to
see. If this is specifically what you are trying to achieve, then you
can't do this with Java at all. A given class can only see one version
of another class at a time...otherwise you get class cast exceptions.
-> richard
> Any help appreciated.
>
> Thanks,
>
> Yair
>
> On Wed, Apr 14, 2010 at 10:38 PM, Richard S. Hall<he...@ungoverned.org>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<heavy@ungoverned.org
>>>
>>>> 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<heavy@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-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
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 <he...@ungoverned.org>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<heavy@ungoverned.org
>> >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<heavy@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-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<he...@ungoverned.org>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<heavy@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-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
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 <he...@ungoverned.org>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<heavy@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-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Yair Ogen <ya...@gmail.com>.
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 <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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: embedded dependencies
Posted by Christopher Brind <ch...@googlemail.com>.
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 <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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: embedded dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org