You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by martin liste larsson <ma...@gmail.com> on 2009/12/01 10:29:47 UTC

Re: Loading multiple versions of the same bundle

On Mon, Nov 30, 2009 at 11:46 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Yes, BND by default generates imports for exports, but you can easily tell
> it not to...check the docs.

Looking at it again, I see that C1 actually imports C2, which is what
you describe. But
it seems a bit strange to me that that should prevent A from importing
C1. If both C1 and
C2 are available, why can't A find C1?

Anyways, I'll fix the imports and be on my way. Thanks for the help. :*)

M.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Loading multiple versions of the same bundle

Posted by martin liste larsson <ma...@gmail.com>.
On Tue, Dec 1, 2009 at 4:35 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> I should be more precise. Assuming the package name is foo, if C1 ends up
> getting wired to C2 for package foo, then C1's version of foo will no longer
> be available for anyone to use, including C1.

Thanks. That's a somewhat non-intuitive, but very logical (yes, that would seem
a paradox) bit of information. Thanks. :*)

M.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Loading multiple versions of the same bundle

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/1/09 10:20, Richard S. Hall wrote:
> On 12/1/09 4:29, martin liste larsson wrote:
>> On Mon, Nov 30, 2009 at 11:46 PM, Richard S. 
>> Hall<he...@ungoverned.org>  wrote:
>>> Yes, BND by default generates imports for exports, but you can 
>>> easily tell
>>> it not to...check the docs.
>> Looking at it again, I see that C1 actually imports C2, which is what
>> you describe. But
>> it seems a bit strange to me that that should prevent A from importing
>> C1. If both C1 and
>> C2 are available, why can't A find C1?
>
> If C1 ends up getting wired to C2, then this means C1 is no longer 
> available, thus A cannot resolve.

I should be more precise. Assuming the package name is foo, if C1 ends 
up getting wired to C2 for package foo, then C1's version of foo will no 
longer be available for anyone to use, including C1.

-> richard

>
> -> richard
>
>> Anyways, I'll fix the imports and be on my way. Thanks for the help. :*)
>>
>> M.
>>
>> ---------------------------------------------------------------------
>> 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: Loading multiple versions of the same bundle

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/1/09 4:29, martin liste larsson wrote:
> On Mon, Nov 30, 2009 at 11:46 PM, Richard S. Hall<he...@ungoverned.org>  wrote:
>    
>> Yes, BND by default generates imports for exports, but you can easily tell
>> it not to...check the docs.
>>      
> Looking at it again, I see that C1 actually imports C2, which is what
> you describe. But
> it seems a bit strange to me that that should prevent A from importing
> C1. If both C1 and
> C2 are available, why can't A find C1?
>    

If C1 ends up getting wired to C2, then this means C1 is no longer 
available, thus A cannot resolve.

-> richard

> Anyways, I'll fix the imports and be on my way. Thanks for the help. :*)
>
> M.
>
> ---------------------------------------------------------------------
> 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