sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [sling-org-apache-sling-feature] 02/22: Add section about OBR
Date Fri, 27 Apr 2018 09:51:22 GMT
This is an automated email from the ASF dual-hosted git repository.

davidb pushed a commit to branch master
in repository

commit 30803cddafec55d6c4c996d63e077df4efad352d
Author: Carsten Ziegeler <>
AuthorDate: Mon Nov 6 12:33:56 2017 +0100

    Add section about OBR
--- | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/ b/
index 2fbf1f4..facc995 100644
--- a/
+++ b/
@@ -208,9 +208,29 @@ This is a feature example:
-# Relation to OBR
+# Relation to Repository Specification (Chapter 132)
+There are two major differences between a repository as described in the Repository Service
Description and the feature model. A repository contains a list of more or less unrelated
resources whereas a feature describes resources as a unit. For example a feature allows to
define a bundle together with OSGi configurations - which ensures that whenever this feature
is used, the bundle *together with* the configurations are deployed. A repository can only
describe the bundle as a separate r [...]
+The second difference is the handling of requirements and capabilities. While a repository
is supposed to list all requirements and capabilities of a resource as part of the description,
the feature model does not require this. As the feature model refers to the bundle and the
bundle has the requirements and capabilities as metadata, there is no need to repeat that
+By these two differences you can already tell, that a repository contents is usually generated
by tools while a feature is usually a human created resource. While it is possible to create
a repository index out of a feature, the other way round does not work as the repository has
no standard way to define relationships between resources.
+# Requirements and Capabilities of Artifacts
+The feature model does not allow to explicitly list requirements or capabilities for artifacts.
An artifact, for example a bundle, contains this information as part of its metadata. However,
to calculate or display these, the tool processing the feature needs to have access to the
artifact and needs to extract this. While in general this does not pose a problem by itself,
it might happen that the same artifact is processed several times for example during a build
process, causing overhead.
+To avoid this, a feature might contain an additional section, named "reqscaps" (TODO find
a better name). This section is grouped by artifact ids and contains the requirements and
capabilities of each artifact. While the requirements and capabilities of a single artifact
must be correct and neither leave out or add additional ones, the list of artifacts must not
be complete. Tooling will first look into this section to get requirements and capabilities
for an artifact. If there are none, [...]
+    {
+        ...
+        "reqscaps" : {
+            "" : {
+                "capabilities" : [],
+                "requirements" : []
+            }
+        }
 # Provisioning Applications

To stop receiving notification emails like this one, please contact

View raw message