sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] cziegeler commented on issue #8: SLING-8104 Avoid magic when merging features
Date Mon, 19 Nov 2018 06:32:07 GMT
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-439785577
 
 
   I totally agree that we don't need special support for HIGHEST, it's already supported
in the sense that the author knows the feature she's including and what version the artifact
there has and she can simply do the right thing.
   Saying that we don't need to support two versions of the same artifact when inheriting
is a little bit dangerous and inconsistent. It's easy to construct cases for it, like the
included feature has three bundles Av1, Bv1 and Cv1 where A and B require Cv1. Now you inherit
from this feature and want to replace B with X which happens to depend on Cv2. If you pick
Cv2, then A doesn't work anymore, if you pick Cv1 then X doesn't work. Or there are other
cases like providing compatibility or a migration strategy etc.
   If we say that "replace" is the common case when inheriting, I think it's simply: we can
say the latest wins, like we do today. Now for the case that both versions are wanted in the
end, the feature that includes simply list the version that replaces *and* the version that
is replaced; listing the same artifact twice with different versions and then it should work
as well. This needs just a slight modification to the current implementation

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


With regards,
Apache Git Services

Mime
View raw message