[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695669#comment-16695669
]
Carsten Ziegeler commented on SLING-8104:
-----------------------------------------
[~bosschaert] That requirement is a different one, it's about launching, not
merging; I think we should keep things separate.
Maybe "override" is not the right term here, its about conflict resolution -
and that's true for framework properties, variables and artifacts - what we put
today into the BuilderContext should really just handle conflicts and no
additional functionality. And this is all about merging features not about
launching. If you want a different artifact version, an additional property
etc. just provide an additional feature with these things and add it to the
merging.
I'm not against providing a way to specify a different version for launching or
adding an additional framework property etc., but that's a different mechanism
than what we're talking about here
> 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.8.0
>
>
> 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)
