"Richard S. Hall" <[EMAIL PROTECTED]> 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 list. > 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
