felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart Elen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-285) Make resolver more robust
Date Tue, 22 May 2007 14:26:16 GMT

    [ https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497876
] 

Bart Elen commented on FELIX-285:
---------------------------------

I just had a look at the newly submitted code. It's looking good and my tests are succeeding.

Great job Richard!


Comment on issue (2):
>From the user his point of view do I think bundles should always be updated. When installing
or updating an application am I expecting that the complete application (= the set of bundles
composing the application) is brought up to date and not just the top application bundle.
The alternative is that the user brings his application up to date by manually determing which
bundles are composing his application and updating them one by one. Not very handy.

>From the very limited device his point of view may this 'user comfort' cause an increase
of the resource usage. Giving the user the task to determine which application bundles should
be updated may save some resources (less network traffic). But it seems doubtful to me that
the gain in resources is worth the trouble for the user.



> Make resolver more robust
> -------------------------
>
>                 Key: FELIX-285
>                 URL: https://issues.apache.org/jira/browse/FELIX-285
>             Project: Felix
>          Issue Type: Improvement
>          Components: Bundle Repository (OBR)
>    Affects Versions: 1.0.0
>            Reporter: Bart Elen
>         Assigned To: Richard S. Hall
>             Fix For: 1.0.0
>
>         Attachments: ResolverImpl.java
>
>
> There are two issues with the resolver of the current OBR implementation:
> 1) It does not try each possible composition
> Suppose we want to install bundle A, and A has a requirement which can be fulfilled by
bundle B or C. B itself has a requirement which can be fulfilled by bundle X and bundle C
has a requirement which can be fulfilled by bundle Y.
> A-B-X
> A-C-Y
> Suppose now that bundle X is not available (or can not be installed on the local platform)
> A-B-
> A-C-Y
> composition A-C-Y is now a correct composition, but the current implementation will notice
that bundle B can not be resolved and will then stop. OBR will not always detect the correct
composition.
> 2) Bundles are not always updated
> Suppose we want to install bundle A which has a requirement which can be fulfilled by
bundle B.
> A-B
> An old version of bundle B is already locally installed on the platform but a newer version
is available on the repository server. The current OBR implementation will detect that the
requirement of A can be met by the locally installed old version of B and it will not check
for a newer version on the repository server.
> I attached a fixed version of ResolverImpl.java in which the described issues are fixed.
> This is my first issue submit ever. Feedback to make it better is appreciated.

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