Should a refresh wire newly added optional dependencies?

["Steele, Richard" <ri...@steelezone.net>]

If a bundle A declares an optional dependency on package com.example.b that
isn't found, I expect that import to be unresolved.  However, if I then add
a bundle (call it B) that exports the package com.example.b, A does not get
wired to B even if I issue a refresh command (though gogo).

Specifically, I'm starting org.springframework.beans, which has an optional
dependency on the net.sf.cglib.proxy package (which is provided by CGLIB).
If I don't have the cglib bundle installed when I start Spring, then the
optional import will forever be unresolved, even if I later install cglib.

Should this work?

Rich

Re: Should a refresh wire newly added optional dependencies?

["Richard S. Hall" <he...@ungoverned.org>]

On 4/14/11 15:12, Richard S. Hall wrote:
> On 4/14/11 14:25, Steele, Richard wrote:
>> On Thu, Apr 14, 2011 at 2:06 PM, Richard S. 
>> Hall<he...@ungoverned.org>wrote:
>>
>>> On 4/14/11 13:55, Steele, Richard wrote:
>>>
>>>> If a bundle A declares an optional dependency on package com.example.b
>>>> that
>>>> isn't found, I expect that import to be unresolved.  However, if I 
>>>> then
>>>> add
>>>> a bundle (call it B) that exports the package com.example.b, A does 
>>>> not
>>>> get
>>>> wired to B even if I issue a refresh command (though gogo).
>>>>
>>> First of all, I don't think the resolver is required to satisfy 
>>> optional
>>> dependencies, but most intuitive implementations probably will.
>>>
>> Are you saying that a package marked as optional might *never* be 
>> resolved
>> even if the package is available?  I never considered that 
>> interpretation of
>> the standard, but when rereading it with that in mind in makes sense.  I
>> guess.
>
> For example, the resolver might use it as an optimization to avoid 
> having to resolve even more dependencies.
>
>> I think most people would be surprised by that behavior.
>
> Agreed, which is why I said most intuitive implementations probably will.
>
>>
>>> Are you specifically refreshing bundle A? If not, then most likely 
>>> nothing
>>> is being refreshed, since a refresh with no parameters only refreshes
>>> updated or uninstalled bundles.
>>
>> Um, no--and that was my problem.
>>
>> I assumed a refresh without any parameters would refresh everything.  In
>> fact, I get no errors from gogo when I do that, so it never dawned on 
>> me to
>> refresh a specific bundle.
>
> It isn't an error, which is why you don't get any. You are just 
> telling it to try to refresh any updated or uninstalled bundles if 
> there are any, but there any 

That should say, "there aren't any"...


> so it succeeds by virtue of the fact that there is nothing to do. This 
> is how the PackageAdmin.refreshPackages() method works, which is what 
> the Gogo command uses.
>
>> This begs the question,
>
> Begging the question means something else altogether, but ignoring 
> that... :-)
>
>> however: assume I install a bundle that many would
>> consider options.  Do I then need to know which bundles to refresh or is
>> there some way the runtime can do this for me?
>>
>> Thanks for the very fast response!
>
> I'm not sure I totally understand. I assume you are saying, you have a 
> bundle on which a lot of other resolved bundles have optional 
> dependencies, but they weren't wired to it because it didn't exist at 
> the time they were resolved, right?
>
> Yeah, there isn't anything you can do here, other than re-resolve them 
> all. Technically, it would be possible to write a command that looks 
> at the exported packages of an installed bundle and checks to see if 
> any other bundles optionally import those packages and if so refresh 
> them. So, if this is a common use case for you, I'd recommend writing 
> such a command...it wouldn't be too difficult.
>
> -> richard
>
>> Rich
>>
>
> ---------------------------------------------------------------------
> 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: Should a refresh wire newly added optional dependencies?

["Steele, Richard" <ri...@steelezone.net>]

> For example, the resolver might use it as an optimization to avoid having
> to resolve even more dependencies.


Ah.


> I'm not sure I totally understand. I assume you are saying, you have a
> bundle on which a lot of other resolved bundles have optional dependencies,
> but they weren't wired to it because it didn't exist at the time they were
> resolved, right?
>

Yes.

Yeah, there isn't anything you can do here, other than re-resolve them all.
> Technically, it would be possible to write a command that looks at the
> exported packages of an installed bundle and checks to see if any other
> bundles optionally import those packages and if so refresh them. So, if this
> is a common use case for you, I'd recommend writing such a command...it
> wouldn't be too difficult.


I understand.  I don't know yet if this is going to be a common use case or
not, but I agree it shouldn't be too hard to implement.

Thanks,
Rich

Re: Should a refresh wire newly added optional dependencies?

["Richard S. Hall" <he...@ungoverned.org>]

On 4/14/11 14:25, Steele, Richard wrote:
> On Thu, Apr 14, 2011 at 2:06 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 4/14/11 13:55, Steele, Richard wrote:
>>
>>> If a bundle A declares an optional dependency on package com.example.b
>>> that
>>> isn't found, I expect that import to be unresolved.  However, if I then
>>> add
>>> a bundle (call it B) that exports the package com.example.b, A does not
>>> get
>>> wired to B even if I issue a refresh command (though gogo).
>>>
>> First of all, I don't think the resolver is required to satisfy optional
>> dependencies, but most intuitive implementations probably will.
>>
> Are you saying that a package marked as optional might *never* be resolved
> even if the package is available?  I never considered that interpretation of
> the standard, but when rereading it with that in mind in makes sense.  I
> guess.

For example, the resolver might use it as an optimization to avoid 
having to resolve even more dependencies.

> I think most people would be surprised by that behavior.

Agreed, which is why I said most intuitive implementations probably will.

>
>> Are you specifically refreshing bundle A? If not, then most likely nothing
>> is being refreshed, since a refresh with no parameters only refreshes
>> updated or uninstalled bundles.
>
> Um, no--and that was my problem.
>
> I assumed a refresh without any parameters would refresh everything.  In
> fact, I get no errors from gogo when I do that, so it never dawned on me to
> refresh a specific bundle.

It isn't an error, which is why you don't get any. You are just telling 
it to try to refresh any updated or uninstalled bundles if there are 
any, but there any so it succeeds by virtue of the fact that there is 
nothing to do. This is how the PackageAdmin.refreshPackages() method 
works, which is what the Gogo command uses.

> This begs the question,

Begging the question means something else altogether, but ignoring 
that... :-)

> however: assume I install a bundle that many would
> consider options.  Do I then need to know which bundles to refresh or is
> there some way the runtime can do this for me?
>
> Thanks for the very fast response!

I'm not sure I totally understand. I assume you are saying, you have a 
bundle on which a lot of other resolved bundles have optional 
dependencies, but they weren't wired to it because it didn't exist at 
the time they were resolved, right?

Yeah, there isn't anything you can do here, other than re-resolve them 
all. Technically, it would be possible to write a command that looks at 
the exported packages of an installed bundle and checks to see if any 
other bundles optionally import those packages and if so refresh them. 
So, if this is a common use case for you, I'd recommend writing such a 
command...it wouldn't be too difficult.

-> richard

> Rich
>

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

Re: Should a refresh wire newly added optional dependencies?

["Steele, Richard" <ri...@steelezone.net>]

On Thu, Apr 14, 2011 at 2:06 PM, Richard S. Hall <he...@ungoverned.org>wrote:

> On 4/14/11 13:55, Steele, Richard wrote:
>
>> If a bundle A declares an optional dependency on package com.example.b
>> that
>> isn't found, I expect that import to be unresolved.  However, if I then
>> add
>> a bundle (call it B) that exports the package com.example.b, A does not
>> get
>> wired to B even if I issue a refresh command (though gogo).
>>
>
> First of all, I don't think the resolver is required to satisfy optional
> dependencies, but most intuitive implementations probably will.
>

Are you saying that a package marked as optional might *never* be resolved
even if the package is available?  I never considered that interpretation of
the standard, but when rereading it with that in mind in makes sense.  I
guess.  I think most people would be surprised by that behavior.


> Are you specifically refreshing bundle A? If not, then most likely nothing
> is being refreshed, since a refresh with no parameters only refreshes
> updated or uninstalled bundles.


Um, no--and that was my problem.

I assumed a refresh without any parameters would refresh everything.  In
fact, I get no errors from gogo when I do that, so it never dawned on me to
refresh a specific bundle.

This begs the question, however: assume I install a bundle that many would
consider options.  Do I then need to know which bundles to refresh or is
there some way the runtime can do this for me?

Thanks for the very fast response!

Rich

Re: Should a refresh wire newly added optional dependencies?

["Richard S. Hall" <he...@ungoverned.org>]

On 4/14/11 13:55, Steele, Richard wrote:
> If a bundle A declares an optional dependency on package com.example.b that
> isn't found, I expect that import to be unresolved.  However, if I then add
> a bundle (call it B) that exports the package com.example.b, A does not get
> wired to B even if I issue a refresh command (though gogo).

First of all, I don't think the resolver is required to satisfy optional 
dependencies, but most intuitive implementations probably will.

Are you specifically refreshing bundle A? If not, then most likely 
nothing is being refreshed, since a refresh with no parameters only 
refreshes updated or uninstalled bundles.

> Specifically, I'm starting org.springframework.beans, which has an optional
> dependency on the net.sf.cglib.proxy package (which is provided by CGLIB).
> If I don't have the cglib bundle installed when I start Spring, then the
> optional import will forever be unresolved, even if I later install cglib.
>
> Should this work?

If you refresh the original bundle, yes.

-> richard

> Rich
>

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