This is an important issue but it's difficult to find a solution that can
apply to everyone. In my case however, I perform an update whenever a newer
version is available from the repository. However, it's not as easy as it
sounds. The "update" caches a newer version but the old version still lurks
in the cache until PackageAdmin.refreshPackages() is called. Unfortunately,
this last action I believe stops the framework (in Felix) or doesn't work
very well from experience. At any rate, my workaround was to simply to
start the new bundle and undeploy the old one. This sequence may not be
exactly correct as I don't have the code in front of me. The other issue I
have was the re-ordering of the bundle-id's after bundles have been removed.
But this perhaps requires another discussion thread...
Rick Litton
----- Original Message -----
From: "Richard S. Hall (JIRA)" <[EMAIL PROTECTED]>
To: <dev@felix.apache.org>
Sent: Saturday, May 19, 2007 11:38 AM
Subject: [jira] Commented: (FELIX-285) Make resolver more robust
[
https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497174 ]
Richard S. Hall commented on FELIX-285:
---------------------------------------
One thing I was thinking about with respect to this patch was that issue
(2) listed above now changes the resolver so that it always performs an
update if one is possible, correct? Ultimately, this is a policy decision
that does not minimize the amount of work that OBR performs. In the old
version of the algorithm, the algorithm minimized the work that it
performed and it took a conscious decision to perform an update (unless
dependencies could not be satisfied with local resources). I am not sure
which is the best approach in this scenario.
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.
