It doesn't sound unreasonable. The only slight caveat is that the
LocalRepository cannot really act like a real Repository, because it can
never provide a URL from which to retrieve locally installed bundles.
Perhaps this would never be an issue, thus making the point moot, but if
for some reason you were providing remote access to the OBR service,
then you wouldn't want it listing locally installed bundles as part of
its result set, since it cannot really offer them.
Perhaps you can create a JIRA issue for this general issue and we can
start to mull over some ideas.
-> richard
Steven E. Harris wrote:
Once again, I'm considering the problem of making sure that a
particular bundle or package is available for use -- and downloading
and installing the required bundles if not.
OBR should help take care of all this. The present Felix OBR
implementation of the RepositoryAdmin.discoverResources() method does
not construct a representation of the "local repository" -- the set of
bundles already installed -- to include in its search. It defers
creating a local repository until it's time to resolve Resources add
to a Resolver. This creates another ambiguity.
Say that I have bundle "foo.bar" installed, but it's not listed in any
of the repository XML files I have fed into
RepositoryAdmin.addRepository(). Next I create a filter:
(symbolicname=foo.bar)
and feed that into RepositoryAdmin.discoverResources(). It will return
an empty set of Resources, as "foo.bar" is not in the provided
repository set.
Now I'm stuck: Is it not possible to acquire "foo.bar", or is it
already available? I can't tell from OBR.
I'd have to call PackageAdmin.getBundles( "foo.bar", null ) and see if
it returns something other than the empty set. Then I'd have to check
if any of the bundles that are present are actually resolved, and if
not, work on trying to convert their unmet requirements to something
OBR could help fulfill.
Now, wouldn't this all be easier if
RepositoryAdmin.discoverResources() considered the local repository as
well? In the case above, it could return a lone Resource for
"foo.bar", which could be fed into a Resolver to make sure it's
properly resolved.
The local resource already gets plucked from the Resolver's set of
required resources, so deploy() would proceed just fine as currently
implemented, ignoring the local resource that isn't eligible for
updating.
It would still be hard to tell whether something got installed or not,
but at least the outcome would be meet the goal: The named bundle is
known to be installed and available for use.
Thoughts?
