[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695086#comment-16695086 ] David Bosschaert commented on SLING-8104: - Thanks for the thoughts, Carsten. I would propose the following for now. When specifying an override for an artifact: * This can be of a version other than in any of the features that declares it. * There can be multiple overrides for a single artifact, i.e. artifact Av1 can be overridden by both Av2 and Av3 * The override must have the same groupID and artifactID - for now. I think we should also allow specifying an override for an artifact that is listed already in a feature but that doesn't clash, this would satisfy [requirement SFL035|https://github.com/apache/sling-org-apache-sling-feature/blob/master/requirements.md]. > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695033#comment-16695033 ] Carsten Ziegeler commented on SLING-8104: - I think an override is an instruction on how to handle a clash. While you might specify more overrides than clashes, these have no influence on the aggregation. To avoid errors we might even argue that specifying an override when there is no clash is an error (same would then be true for overrides for framework properties etc.) An override might definitely specify a different version, I guess it would also make sense to specify different coordinates to resolve the clash; I'm not sure if we need it now, so we can either implement it now or wait until it's needed. > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694900#comment-16694900 ] David Bosschaert commented on SLING-8104: - Ok, then I guess it should also be allowed to specify an artifact override even if there isn't a clash. Then that brings me to the following thought. How about an override that has a different groupId/artifactId? This can currently not be specified... > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694892#comment-16694892 ] Carsten Ziegeler commented on SLING-8104: - [~bosschaert] Sure, any version should be allowed > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694884#comment-16694884 ] David Bosschaert commented on SLING-8104: - I was thinking a little more about this and was wondering: should an artifact override allow the specification of an artifact version that wasn't in any feature initially? So lets's say a feature X defines bundle g:a:1 and feature Y defines bundle g:a:2. Would it be acceptable for an artifact override to state that bundle g:a:3 is used in this case (even if neither feiture declares that one)? /cc [~cziegeler] > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694497#comment-16694497
]
ASF GitHub Bot commented on SLING-8104:
---
bosschaert closed pull request #9: SLING-8104 Avoid magic when merging features
URL: https://github.com/apache/sling-org-apache-sling-feature/pull/9
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
b/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
index 1dd100c..61acba5 100644
--- a/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
+++ b/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
@@ -29,10 +29,6 @@
*/
public class BuilderContext {
-enum ArtifactMergeAlgorithm {
-LATEST, HIGHEST
-}
-
/** The required feature provider */
private final FeatureProvider provider;
@@ -42,10 +38,10 @@
private final Map> extensionConfiguration = new
HashMap<>();
private final List mergeExtensions = new ArrayList<>();
private final List postProcessExtensions = new
ArrayList<>();
+private final List artifactsOverrides = new ArrayList<>();
private final Map variables = new HashMap<>();
private final Map frameworkProperties = new HashMap<>();
-private ArtifactMergeAlgorithm merge = ArtifactMergeAlgorithm.HIGHEST;
/**
* Create a new context
@@ -72,27 +68,38 @@ public BuilderContext setArtifactProvider(final
ArtifactProvider ap) {
}
/**
- * Add overwrites for the variables
+ * Add overrides for the variables
*
- * @param vars The overwrites
+ * @param vars The overrides
* @return The builder context
*/
-public BuilderContext addVariablesOverwrites(final Map
vars) {
+public BuilderContext addVariablesOverrides(final Map vars)
{
this.variables.putAll(vars);
return this;
}
/**
- * Add overwrites for the framework properties
+ * Add overrides for the framework properties
*
- * @param props The overwrites
+ * @param props The overrides
* @return The builder context
*/
-public BuilderContext addFrameworkPropertiesOverwrites(final
Map props) {
+public BuilderContext addFrameworkPropertiesOverrides(final
Map props) {
this.frameworkProperties.putAll(props);
return this;
}
+/**
+ * Add overrides for artifact clashes
+ *
+ * @param overrides The overrides
+ * @return The builder context
+ */
+public BuilderContext addArtifactsOverrides(final List overrides) {
+this.artifactsOverrides.addAll(overrides);
+return this;
+}
+
/**
* Add merge extensions
*
@@ -115,17 +122,6 @@ public BuilderContext addPostProcessExtensions(final
PostProcessHandler... exten
return this;
}
-/**
- * Set the merge algorithm
- *
- * @param alg The algorithm
- * @return The builder context
- */
-public BuilderContext setMergeAlgorithm(final ArtifactMergeAlgorithm alg) {
-this.merge = alg;
-return this;
-}
-
/**
* Set a handler configuration
*
@@ -152,11 +148,15 @@ ArtifactProvider getArtifactProvider() {
return this.artifactProvider;
}
-Map getVariablesOverwrites() {
-return this.variables;
+List getArtifactOverrides() {
+return this.artifactsOverrides;
+}
+
+Map getVariablesOverrides() {
+return this.variables;
}
-Map getFrameworkPropertiesOverwrites() {
+Map getFrameworkPropertiesOverrides() {
return this.frameworkProperties;
}
@@ -168,10 +168,6 @@ FeatureProvider getFeatureProvider() {
return this.provider;
}
-ArtifactMergeAlgorithm getMergeAlgorithm() {
-return this.merge;
-}
-
/**
* Get the list of merge extensions
* @return The list of merge extensions
@@ -196,11 +192,11 @@ ArtifactMergeAlgorithm getMergeAlgorithm() {
BuilderContext clone(final FeatureProvider featureProvider) {
final BuilderContext ctx = new BuilderContext(featureProvider);
ctx.setArtifactProvider(this.artifactProvider);
+ctx.artifactsOverrides.addAll(this.artifactsOverrides);
ctx.variables.putAll(this.variables);
ctx.frameworkProperties.putAll(this.frameworkProperties);
ctx.mergeExtensions.addAll(mergeExtensions);
ctx.postProcessExtensions.addAll(postProcessExtensions);
-ctx.merge = this.merge;
return ctx;
}
}
diff --git a/src/main/java/org/apache/sling/feature/builder/BuilderUtil.java
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692293#comment-16692293 ] ASF GitHub Bot commented on SLING-8104: --- bosschaert opened a new pull request #9: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/9 When merging artifacts/bundles, they need to be selected from a provided override list if the artifact versions are not the same. The list has the following syntax: * `groupid1:artifactid1:` * `groupid2:artifactid2:` To apply the same override rule for all clashes, a wildcard using '*' for groupID and artifactID can be used: * `*:*:` means always select the same resolution in case of a clash. Where `` is one of the following: * `ALL` - select all the artifacts * `HIGHEST` - select only the artifact with the highest version number * `LATEST` - select only the artifact provided latest * `` - select this specific version When comparing version numbers these are converted to OSGi version numbers and the OSGi version number ordering is applied. When merging includes artifacts specified in the target feature override all artifacts with the same group ID and artifact ID in the included feature. Both the included as well the target feature can have multiple artifacts with the same group ID and artifact ID but different versions. 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692294#comment-16692294 ] 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-440044890 New pull request: https://github.com/apache/sling-org-apache-sling-feature/pull/9 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692277#comment-16692277 ] 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-440040665 I'm closing this pull request as it has conflicts with master. I'll rebase and create a new pull request. 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692278#comment-16692278
]
ASF GitHub Bot commented on SLING-8104:
---
bosschaert closed pull request #8: SLING-8104 Avoid magic when merging features
URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
b/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
index 1dd100c..f97d43d 100644
--- a/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
+++ b/src/main/java/org/apache/sling/feature/builder/BuilderContext.java
@@ -29,10 +29,6 @@
*/
public class BuilderContext {
-enum ArtifactMergeAlgorithm {
-LATEST, HIGHEST
-}
-
/** The required feature provider */
private final FeatureProvider provider;
@@ -42,10 +38,10 @@
private final Map> extensionConfiguration = new
HashMap<>();
private final List mergeExtensions = new ArrayList<>();
private final List postProcessExtensions = new
ArrayList<>();
+private final List artifactsOverrides = new ArrayList<>();
private final Map variables = new HashMap<>();
private final Map frameworkProperties = new HashMap<>();
-private ArtifactMergeAlgorithm merge = ArtifactMergeAlgorithm.HIGHEST;
/**
* Create a new context
@@ -93,6 +89,17 @@ public BuilderContext addFrameworkPropertiesOverwrites(final
Map
return this;
}
+/**
+ * Add overrides for artifact clashes
+ *
+ * @param overrides The overwrites
+ * @return The builder context
+ */
+public BuilderContext addArtifactsOverrides(final List overrides) {
+this.artifactsOverrides.addAll(overrides);
+return this;
+}
+
/**
* Add merge extensions
*
@@ -115,17 +122,6 @@ public BuilderContext addPostProcessExtensions(final
PostProcessHandler... exten
return this;
}
-/**
- * Set the merge algorithm
- *
- * @param alg The algorithm
- * @return The builder context
- */
-public BuilderContext setMergeAlgorithm(final ArtifactMergeAlgorithm alg) {
-this.merge = alg;
-return this;
-}
-
/**
* Set a handler configuration
*
@@ -152,8 +148,12 @@ ArtifactProvider getArtifactProvider() {
return this.artifactProvider;
}
+List getArtifactOverrides() {
+return this.artifactsOverrides;
+}
+
Map getVariablesOverwrites() {
-return this.variables;
+return this.variables;
}
Map getFrameworkPropertiesOverwrites() {
@@ -168,10 +168,6 @@ FeatureProvider getFeatureProvider() {
return this.provider;
}
-ArtifactMergeAlgorithm getMergeAlgorithm() {
-return this.merge;
-}
-
/**
* Get the list of merge extensions
* @return The list of merge extensions
@@ -196,11 +192,11 @@ ArtifactMergeAlgorithm getMergeAlgorithm() {
BuilderContext clone(final FeatureProvider featureProvider) {
final BuilderContext ctx = new BuilderContext(featureProvider);
ctx.setArtifactProvider(this.artifactProvider);
+ctx.artifactsOverrides.addAll(this.artifactsOverrides);
ctx.variables.putAll(this.variables);
ctx.frameworkProperties.putAll(this.frameworkProperties);
ctx.mergeExtensions.addAll(mergeExtensions);
ctx.postProcessExtensions.addAll(postProcessExtensions);
-ctx.merge = this.merge;
return ctx;
}
}
diff --git a/src/main/java/org/apache/sling/feature/builder/BuilderUtil.java
b/src/main/java/org/apache/sling/feature/builder/BuilderUtil.java
index ad804d9..4af8580 100644
--- a/src/main/java/org/apache/sling/feature/builder/BuilderUtil.java
+++ b/src/main/java/org/apache/sling/feature/builder/BuilderUtil.java
@@ -23,13 +23,15 @@
import org.apache.sling.feature.Extension;
import org.apache.sling.feature.Feature;
import org.apache.sling.feature.FeatureConstants;
-import org.apache.sling.feature.builder.BuilderContext.ArtifactMergeAlgorithm;
+import org.osgi.framework.Version;
import org.osgi.resource.Capability;
import org.osgi.resource.Requirement;
import java.io.StringReader;
import java.io.StringWriter;
import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.List;
@@ -50,6 +52,7 @@
* Utility methods for the builders
*/
class BuilderUtil {
+static final String CATCHALL_OVERRIDE = "*:*:";
static boolean contains(String key, Iterable>
itera
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691615#comment-16691615 ] 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-439870266 Thanks @cziegeler that approach works for me. I'll have a look at supporting that. 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691294#comment-16691294 ] ASF GitHub Bot commented on SLING-8104: --- 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689281#comment-16689281 ] 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-439357538 Hi @cziegeler thanks for reviewing. > The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well Yes, I'm planning to do this separately. Good point on the includes - I'll update this pull request with an implementation along the lines of what you have suggested. 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689080#comment-16689080 ] ASF GitHub Bot commented on SLING-8104: --- 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-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. 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688246#comment-16688246 ] 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-439086668 Note that the slingfeature-maven-plugin changes to provide the artifact override list is being developed here: https://github.com/bosschaert/sling-slingfeature-maven-plugin/tree/SLING-8104 @cziegeler @karlpauls WDYT? 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688237#comment-16688237 ] ASF GitHub Bot commented on SLING-8104: --- bosschaert opened a new pull request #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8 When merging artifacts/bundles, they need to be selected from a provided override list if the artifact versions are not the same. The list has the following syntax: groupid1:artifactid1: groupid2:artifactid2: Where is one of the following: ALL - select all the artifacts HIGHEST - select only the artifact with the highest version number LATEST - select only the artifact provided latest - select this specific version When comparing version numbers these are converted to OSGi version numbers and the OSGi version number ordering is applied. 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: us...@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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687839#comment-16687839 ] David Bosschaert commented on SLING-8104: - Works for me :) thanks! > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687832#comment-16687832
]
Carsten Ziegeler commented on SLING-8104:
-
This looks a little bit strange :) What about :
{noformat}
mygid:org.foo.my.bundle:1.2.3
mygid:org.foo.my.bundle:HIGHEST
mygid:org.foo.my.bundle:ALL
> 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687809#comment-16687809
]
David Bosschaert commented on SLING-8104:
-
{quote}In addition your syntax above does not work in XML as a colon is
separating namespace from the element name.
{quote}
Of course, yes. And the forward slash {{/}} is also not allowed.
Maybe the cleanest solution would be to embed the elements in group ID tags,
like this.
{code:java}
1.2.3
{code}
Although I'm not 100% sure I can parse this in the MOJO. Another possibility
could be to use another separator, like an underscore:
{code:java}
1.2.3
{code}
> 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687557#comment-16687557 ] Carsten Ziegeler commented on SLING-8104: - Yes, the mechanism needs to be based on the artifact gavs; I think your proposal makes sense The only thing is naming, we already have a similar approach for variables and framework properties. However in the configuration these are just called "variables" and "frameworkProperties" . In the code we call it overwrites. So I suggest we go with variablesOverwrites frameworkPropertiesOverwrites artifactsOverwrites or pick a different word for "Overwrites" - but I hthink we should use the same naming In addition your syntax above does not work in XML as a colon is separating namespace from the element name. > 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)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686972#comment-16686972
]
David Bosschaert commented on SLING-8104:
-
Maybe we could have a mechanism as follows: if more than one feature provides a
certain artifact (bundle) then, if both are _not_ exactly the same some
configuration needs to be present to do the resolution. Otherwise the merge
will fail.
For example maybe some configuration in the creation of the aggregate in the
slingfeature-maven-plugin, like this:
{code:java}
...
...
1.2.3
HIGHEST(1.*)
HIGHEST
ALL
{code}
I think the mechanism should work on artifact gav's rather than bsn/version
since the merger only knows about artifacts. This also makes the mechanism more
generic.
Just an initial proposal, would be more than happy with improvement
suggestions. Note that the launcher will also need a mechanism to specify this.
> 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
>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 bundle 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)
