felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4525) Refactor the Framework to use the Resolver module
Date Mon, 15 Sep 2014 18:15:35 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134226#comment-14134226

Richard S. Hall commented on FELIX-4525:

Ok, I spent a little more time looking at this, but I am having trouble remembering an idea
for dynamic imports that I had way back when the resolver was spec'ed. I thought I put some
comments in the code, but I cannot find them.

So, at this point, it is probably most prudent to just use the variant ResolverImpl.resolve()
method that accepts a dynamic requirement and a list of matches. This is pretty close to what
we were doing before, so it shouldn't be too difficult to port. This is the same approach
Tom uses in Equinox.

We will also need to adjust how we do fragments. Tom introduced a new way of introducing "on
demand" resources, which is how we were treating fragments too. The new approach is more incremental,
where our old approach just passed in all fragments via the resolve context and then the result
would attempt to determine if they were necessary. In the new approach the resolver asks the
resolve context if it wants to add more resources when it pulls in new candidates, which works
for pulling in fragments when you pull in a new host.

> Refactor the Framework to use the Resolver module
> -------------------------------------------------
>                 Key: FELIX-4525
>                 URL: https://issues.apache.org/jira/browse/FELIX-4525
>             Project: Felix
>          Issue Type: Task
>          Components: Framework
>    Affects Versions: framework-4.4.0
>            Reporter: David Bosschaert
>            Assignee: David Bosschaert
>             Fix For: framework-4.6.0
> Currently both the framework has a resolver implementation as well as the resolver module,
which has a separate resolver implementation. The resolver module originates from the framework,
but they are not the same any more.
> It would be good to refactor the framework to use the resolver implementation from the
resolver module so that there is no code duplication any more.

This message was sent by Atlassian JIRA

View raw message