[
https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497896
]
Richard S. Hall commented on FELIX-285:
---------------------------------------
I will close this issue then, but feel free to keep commenting on it for
posterity.
I would say thay your view on issue (2) presupposes the existence of an
"application" concept, which does not explicitly exist and may not implicitly
exist or may not exist in isolation. Certainly, an "application" concept
doesn't exist in the OSGi sense of it, but it may also be the case that some
functionality is created by an ad hoc collection of independently developed
bundles, thus there is no a priori definition of this application. Further,
even if there is an implicit application concept, if multiple applications
reside within the same framework, then updating shared components could
interfere with the other. Since the application concept is implicit, there is
no way to reason about such application-level constraints.
Still, in the end, the decision even within a single application of whether or
not all components should be updated is a policy decision, which is generally
decided by incrementing your versioned dependencies so that you can no longer
be resolved to older versions. If the application specifically allows older
versions to satisfy its dependencies, then it can be easily argued that
updating everything is unnecessary.
None of this is a major issue vis a vis this patch, these are just issues that
will have to sorted out at some point in the future.
> 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.
