Author: cziegeler
Date: Mon Jul 3 15:06:19 2017
New Revision: 1800684
URL: http://svn.apache.org/viewvc?rev=1800684&view=rev
Log:
Update readme
Modified:
sling/whiteboard/cziegeler/feature/readme.md
Modified: sling/whiteboard/cziegeler/feature/readme.md
URL:
http://svn.apache.org/viewvc/sling/whiteboard/cziegeler/feature/readme.md?rev=1800684&r1=1800683&r2=1800684&view=diff
==============================================================================
--- sling/whiteboard/cziegeler/feature/readme.md (original)
+++ sling/whiteboard/cziegeler/feature/readme.md Mon Jul 3 15:06:19 2017
@@ -1,10 +1,10 @@
-# Prototype for a new Provisioning Model - Configuration Model for OSGi based
applications
+# Prototype for a new Provisioning Model - Configuration Model for OSGi based
applications
The current model to describe OSGi applications is based on Apache Sling's
provisioning model (see
https://sling.apache.org/documentation/development/slingstart.html)
## Short description of Sling's provisioning model:
-* Text based file format, defining features
+* Text based file format, defining features (several in a single file)
* A feature can have a name and version (both optional)
* A feature consists of sections, well defined ones like the run modes and
user defined sections
* A run mode has artifacts (with start levels), configurations and settings
(framework properties)
@@ -31,6 +31,7 @@ The current model to describe OSGi appli
* API (object relation) differs from text file (to make the text format easier)
* Tooling only available as maven plugins, not separate usable
* Run mode handling is complicating the feature files and processing of those
+* Tightly coupled with the way Sling's launchpad works, therefore no
independent OSGi format
# Design Criteria for a model
@@ -39,7 +40,7 @@ The current model to describe OSGi appli
* No support for run modes in the model - run modes can be modeled through
separate features
* OSGi JSON format for configurations
* Support for standard OSGi artifacts as well as custom artifacts (like
content packages)
-* Support OSGi requirements and capabilities for dependency Handling
+* Support OSGi requirements and capabilities for dependency handling
# Prototype
@@ -48,7 +49,7 @@ The prototype uses JSON as a well define
A model file describes a feature. A feature consists of:
* A unique id and version (see Feature Identity below)
* A list of bundles described through maven coordinates
- * Start level
+ * Grouped by start level (required)
* Additional metadata like a hash etc. (optional)
* Configurations (optional)
* A set of global configurations
@@ -77,7 +78,7 @@ Maven coordinates are used to describe a
In order to avoid a concept like "Require-Bundle" a feature does not
explicitely declare dependencies to other features. These are declared by the
required capabilities, either explicit or implicit. The implicit requirements
are calculated by inspecting the contained bundles (and potentially other
artifacts like content packages ).
-Once a feature is processed by tooling, the tooling might create a full list
of requirements and capabilities and add this information in a special section
to the final feature. This information can be used by tooling to validate an
instance (see below) and avoids rescanning the binary artifacts. However this
"cached" information is optional and tooling must work without it (which means
it needs access to the binaries in that case)
+Once a feature is processed by tooling, the tooling might create a full list
of requirements and capabilities and add this information in a special section
to the final feature. This information can be used by tooling to validate an
instance (see below) and avoids rescanning the binary artifacts. However this
"cached" information is optional and tooling must work without it (which means
it needs access to the binaries in that case). TBD the name and format of this
information.
# Includes
@@ -95,11 +96,18 @@ Once a feature is processed, included re
* If the last configuration does not belong to a bundle and has no
property removal instruction, the relationship from the first bundle is used
(if there is one)
* If the last configuration has a property removal instruction for the
bundle relationship, the resulting configuration is unbound
* Later framework properties overwrite newer ones
-* Capabilities and requirements are appended
-* Extensions are handled in an exptension specific way:
+* Capabilities and requirements are appended - this might result in
duplicates, but that doesn't really hurt in practice.
+* Extensions are handled in an extension specific way:
* repoinit is just aggregated (appended)
* artifact extensions are handled like bundles
+# Extensions
+
+An extension has a unique name and a type which can either be text, JSON or
artifacts. Depending on the type, inheritance is performed like this:
+* For type text: simple appended
+* For type JSON: merging of the JSON structure, later arriving properties
overriding existing ones
+* For type artifacts: merging of the artifacts, higher version wins
+
# Handling of Environments
A feature itself has no special support for environments (prod, test, dev). In
practice it is very unlikely that a single file exists containing
configurations for all environments, especially as the configuration might
contain secrets, credentials, urls for production services etc which are not
meant to be given out in public (or to the dev department). Instead, a separate
feature for an environment can be written and maintained by the different share
holders which adds the environment specific configuration. Usually this feature
would include the feature it is based on.
