felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (FELIX-280) OBR should be able to confirm satisfaction of a filter, including availability of local resources
Date Fri, 26 Feb 2010 00:00:28 GMT

     [ 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.


Mime
View raw message