felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven E. Harris" <...@panix.com>
Subject Re: OBR Resolver.deploy() and framework start level
Date Mon, 12 Feb 2007 18:03:41 GMT
"Richard S. Hall" <heavy@ungoverned.org> writes:

> And, in general, it is not a good idea to make expedient decisions
> because then it is hard to back away from them later.

I understand.

> The resource gives you the symbolic name and version, which uniquely
> identifies the bundle.

Yes, though unfortunately it's still an O(n) search to find the bundle
this way.


> There is no association between a resource and an installed bundle
> under the covers as you imply other than this.

By "association", I was referring to the body of the Resolver.deploy()
function which, while building its "start list" in the present
incarnation, is able to get an actual Bundle instance in hand for each
Resource it's operating on. It could return this "start list" to the
caller as a Set<Bundle> or Bundle[], but we'd still be arguing over
whether already-installed Bundles should be included in the returned

> A thought, I could imagine another possibility, where the deploy()
> method could return some sort of mapping between its resources and
> the bundles it deployed or there could be another method that
> returned this mapping after deploy() was invoked, since the resolver
> would be able to construct this mapping while deploying the
> resources.

Yes, that's what I'm alluding to above. It could be the return value
from deploy(), which at the moment only returns void, or it could be
fetched by a subsequent method call if constructing the mapping is too
expensive to do by default (even though it is best built during the
deploy() method).

As for whether it's a mapping from Resource->Bundle or just the
Bundles themselves, I don't see much of a difference for my use
case. I just want the Bundles.

Steven E. Harris

View raw message