[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691034#comment-16691034
]
ASF GitHub Bot commented on SLING-8104:
---------------------------------------
bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features
URL:
https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439724403
Hi @cziegeler I thought a little bit more about the includes…
I totally agree that the includes should be processed without the needs for
external overrides.
However I'm not sure that supporting two concurrent versions with an include
is necessary. With an include you are creating a new feature while using an
existing feature as its prototype. Basically you take an existing feature that
comes close to what you need, tweak that and as such define a new feature.
When you create a normal feature (without using includes) you wouldn’t
create a feature with the same bundle in different versions twice, would you?
So why support two different versions through the includes/prototype mechanism?
I think side-by-side versions could be useful when one feature provides a
capability required by another feature, but to define a single feature with two
identical bundles with different versions side-by-side sounds like an unlikely
edge case.
I think a simpler approach is as follows. Given a bundle Xv2 in feature A
that includes feature I which also declared bundle Xv1, this should simply
select the bundle Xv2 from feature A as you are tweaking the definition of I in
A. If you want to select Xv1 from I you simply remove it from the definition of
A.
The case where a HIGHEST algorithm should be used is confusing here IMHO
because let’s say I defines Xv3 instead of Xv1, then it would still be
confusing/strange if the include would override the entity that is including
it. A prototype object normally doesn’t override/ignore any specialisations
made to it, so I would not support this algorithm for the Includes case.
My 2c :)
David
----------------------------------------------------------------
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)
