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: [email protected] With regards, Apache Git Services
