[jira] Resolved: (FELIX-280) OBR should be able to confirm satisfaction of a filter, including availability of local resources

["Guillaume Nodet (JIRA)" <ji...@apache.org>]

     [ 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/dev@felix.apache.org/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.