[
https://issues.apache.org/jira/browse/FELIX-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-280.
-----------------------------------
Resolution: Duplicate
Fix Version/s: bundlerepository-1.6.0
Assignee: Guillaume Nodet
Closing this issue as a duplicate
> OBR should be able to confirm satisfaction of a filter, including
> availability of local resources
> -------------------------------------------------------------------------------------------------
>
> Key: FELIX-280
> URL: https://issues.apache.org/jira/browse/FELIX-280
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
> Affects Versions: felix-1.0.0
> Environment: NA
> Reporter: Steven E. Harris
> Assignee: Guillaume Nodet
> Fix For: bundlerepository-1.6.0
>
>
> This discussion started on the felix-dev list in the thread entitled
> Should OBR RepositoryAdmin.discoverResources() include local repository?
> http://www.mail-archive.com/[email protected]/msg00071.html
> The root problem involves considering the filter supplied to
> RepositoryAdmin.discoverResources() as a goal, and wanting OBR to help in
> achieving that goal, including the possibility that no additional steps are
> required to satisfy the goal. That is, the current state of the local
> repository may satisfy the goal, even though no remote repository can offer
> anything. A client attempting to meet such a goal should still be able to
> discern that its goal has been met.
> At present, the OBR workflow starts with a client calling
> RepositoryAdmin.discoverResources(), locating Resources available in remote
> repositories matching the supplied filter. These Resources are then fed into
> a Resolver, which figures out what additional Resources may be needed to
> satisfy the root Resources' requirements. Some of these Requirements may be
> satisfied by resources already available locally, as represented in the local
> repository.
> If a client seeks to ensure that, say, bundle "foo.bar" of version "1.0" is
> available for use, he can supply a filter like
> (&(symbolicname=foo.bar)(version=1.0))
> to RepositoryAdmin.discoverResources() and see which Resources can fulfil
> this goal. However, if this bundle is not available in any remote
> repositories, but is already available locally, OBR still signals failure, or
> at least defeat. The client cannot tell that its goal is already fulfilled.
> My first suggestion was to have RepositoryAdmin.discoverResources() take the
> local repository into account as a source for Resources. However, this isn't
> quite what the problem demands.
> Really, we want a way to turn a filter into a set of Requirements to be added
> to a Resolver. Alternately, we'd like to be able to feed a filter directly
> into a Resolver to add match criteria, much like Resolver.add() allows one to
> add a Resource as both a goal and a source of Requirements.
> We should be able to skip the RepositoryAdmin.discoverResources() step
> entirely and instead call an overload of Resolver.add() that either takes a
> Filter or a String representing a filter to be parsed.
> The current workflow oscillates somewhat strangely between identification of
> matching Resources and adding more Resources to satisfy additional discovered
> Requirements. Why even bother exposing the first set of Resources matched,
> forcing the client to push them into the Resolver? As
> RepositoryAdmin.discoverResources() is the only way that a client can cause a
> Resource to be emitted (Resources not being constructible by a client), their
> only path flows between RepositoryAdmin.discoverResources() and
> Resolver.add(). We could just close that gap and allow Resolver to process a
> filter internally, with full access to the local repository as well.
> With changes like these in place, my scenario involving a resource available
> locally but not remotely would be accommodated: If, after adding my filter to
> a Resolver, Resolver.resolve() returns true, I know my goal can be satisfied.
> Calling Resolver.deploy() in that case would be a no-op, but should succeed
> without error nonetheless.
> One problem I see implementing such a solution is the Filter class itself.
> Filters as defined in OSGi are opaque and one-way: one can only ask if a
> filter matches a Dictionary, not "ask" a filter what it demands. Hence, a
> Filter can't be converted to a set of Requirement instances. It can only act
> like a set of Requirements in its matching behavior.
> Note that the whole filter could be bypassed if we had some public
> Requirement factory functions, such as:
> public static Requirement requireBundle(String symbolicName);
> public static Requirement requireBundle(String symbolicName, String
> versionConstraint);
> public static Requirement requirePackage(String packageName);
> public static Requirement requirePackage(String packageName, String
> versionConstraint);
> Then, add a method to Resolver:
> add(Requirement req);
> I'd appreciate some discussion of the viability of these suggestions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
