sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SLING-8104) Avoid magic when merging features
Date Fri, 16 Nov 2018 08:27:00 GMT

    [ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689160#comment-16689160
] 

ASF GitHub Bot commented on SLING-8104:
---------------------------------------

cziegeler edited a comment 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.
   Or we don't have a replace section which then requires to remove a bundle if A wants to
provide a different version:
   If A removes the bundle inherited from I and adds a new one (== LATEST)
   If A lists a bundle in the bundles section, both versions will be included (==ALL)
   
   The first option makes it easier to change the version of a bundle, but introduces a new
concept just for this use case.
   

----------------------------------------------------------------
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:
users@infra.apache.org


> 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)

Mime
View raw message