[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689080#comment-16689080
]
ASF GitHub Bot commented on SLING-8104:
---------------------------------------
cziegeler commented on issue #8: SLING-8104 Avoid magic when merging features
URL:
https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439295972
This looks basically good to me, two comments:
The other methods in the BuilderContext should be renamed from *Overwrites
to *Overrides as well
The new mechanism is now also used to process an include; however I think an
include should be processable without providing additional information. So far,
the latest artifact won, meaning that the one from the feature that has the
include wins, which seems logical. On the other hand, this prevents the use
case of having both versions. We already have the "remove" section in an
include, we could add a "replace" section there as well which then means:
Let's assume feature A includes feature I.
If A lists a bundle in the replace section, this bundle version will win (==
LATEST)
If A lists a bundle in the bundles section, both versions will be included
(== ALL)
The decision for a HIGHEST is done by the feature author.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Avoid magic when merging features
> ---------------------------------
>
> Key: SLING-8104
> URL: https://issues.apache.org/jira/browse/SLING-8104
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
> Reporter: Carsten Ziegeler
> Assignee: David Bosschaert
> Priority: Blocker
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2
>
>
> Currently when features are merged a simple algorithm is applied which just
> picks the highest version based on the artifact version. However this version
> might not have no meaning at all and might not really reflect what has
> changed inside the bundle.
> Especially when there is a major version change, this approach seems to be
> clearly wrong
> But in the end, picking a single version is magic.
> While the problem could probably be solved by using something like a resolver
> and figure out if just one version is enough or if both versions are needed,
> without a resolver there is no way to figure this out.
> Therefore we should provide a similar way as we do for variables at the
> moment: if there is a clash the caller needs to provide context on what to
> choose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
