[sling-org-apache-sling-feature] branch master updated: Update docs about prototypes

[cz...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

cziegeler pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/sling-org-apache-sling-feature.git


The following commit(s) were added to refs/heads/master by this push:
     new a1b8ecd  Update docs about prototypes
a1b8ecd is described below

commit a1b8ecd3892194fd182a73c559a5a935b95455a2
Author: Carsten Ziegeler <cz...@apache.org>
AuthorDate: Mon Sep 7 17:49:48 2020 +0200

    Update docs about prototypes
---
 docs/features.md | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/docs/features.md b/docs/features.md
index 52e5933..c81c001 100644
--- a/docs/features.md
+++ b/docs/features.md
@@ -261,13 +261,29 @@ Then the removal instructions of the prototype object are handled next.
 Finally, the contents from the prototype is then overlayed with the definitions from the feature using the prototype. In detail this means:
 
 * Variables from the feature overwrite variables from the prototype.
-* A clash of artifacts (such as bundles) between the prototype and the feature is resolved by picking the version from the feature, not its prototype. Artifact clashes are detected based on Maven Coordinates, not on the content of the artifact. So if a prototype defines a bundle with artifact ID `org.sling:somebundle:1.2.0` and the feature itself declares `org.sling:somebundle:1.0.1` in its `bundles` section, the bundle with version `1.0.1` is used.
+* A clash of artifacts (such as bundles) between the prototype and the feature is not resolved and both versions end up in the featuree. Artifact clashes are detected based on Maven Coordinates, not on the content of the artifact. So if a prototype defines a bundle with artifact ID `org.sling:somebundle:1.2.0` and the feature itself declares `org.sling:somebundle:1.0.1` in its `bundles` section, version `1.0.1` and version `1.2.0` are used. The removals section can be used to remove the  [...]
 * Configurations will be merged by default, the ones from the feature potentially overwriting configurations from the prototype:
   * If the same property is declared in more than one feature, the last one wins - in case of an array value, this requires redeclaring all values (if they are meant to be kept).
 * Framework properties from the feature overwrite framework properties from the prototype.
 * Extensions are handled in an extension specific way, by default the contents are appended. In the case of extensions of type `Artifact` these are handled just like bundles. Extension merge plugins can be configured to perform custom merging.
 * Capabilities and requirements are appended - this might result in duplicates, but that doesn't really hurt in practice.
 
+```json
+Example for removing artifacts:
+{
+  "id" : "org.apache.sling:my-sling-core-feature:slingosgifeature:1.0.0",
+  "prototype" : {
+     "id" : "org.apache.sling:org.apache.sling.core.feature:slingosgifeature:1.0.0",
+     "removals" : {
+       "bundles" : [
+         "org.apache.sling:org.apache.sling.foo:1.0.1", // only the exact version 1.0.1 is removed
+         "org.apache.sling:org.apache.sling.bar:0"      // any version from the prototype is removed
+       ]
+     }
+  }
+}
+```
+
 ## Final and Complete Features
 
 A feature might be self-contained, for example a feature describing a complete application has no external dependencies. Such a feature can be marked as `complete` indicating