Steven E. Harris wrote:
"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.
[...]
True, but I would assume that n is reasonably small since we are talking
about installed bundles...even a 1000 or so shouldn't be an issue. If it
is, you can easily construct your own map of installed bundles to search
faster, since it isn't optimized under the covers either for quick
lookup by symbolic name and version.
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.
Well, I am not against such an extension. We could always sub-class the
resolver interface so we don't break from the "official" interface and
add a method to get this mapping post-deploy().
I also think the resolver interface needs to be extended pre-deploy() to
give a better indication of what will be installed and what will be
updated (and possibly in the future, removed)...that is another
different, but related issue.
-> richard
