Author: cziegeler
Date: Thu Aug 31 13:02:58 2017
New Revision: 1806790
URL: http://svn.apache.org/viewvc?rev=1806790&view=rev
Log:
Update section about start levels
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=1806790&r1=1806789&r2=1806790&view=diff
==============================================================================
--- sling/whiteboard/cziegeler/feature/readme.md (original)
+++ sling/whiteboard/cziegeler/feature/readme.md Thu Aug 31 13:02:58 2017
@@ -116,6 +116,10 @@ A feature itself has no special support
For bundles there is no default start level - a default start level is not
defined in the OSGi spec. And in addition, it is a little bit confusing when
looking at the model when there is a list of artifacts without a start level.
Which start level do these have? Its better to be explicit.
+In the current PoC, a bundle needs to be explicitely assigned to a start
level. This seems to be only working if you know all the features in advance
and how they are structured. On the other hand there needs to be a way to
define the start order of bundles within a feature. Therefore we can use the
start level information as an ordering information for the bundles within a
feature. Bundles within the same start level are started in any order.
+
+Proposal: We use the format as it is today, but interpret the start level
value different: instead of directly mapping it to a start level in the OSGi
framework, it defines just the startup order of bundles within a feature.
Features are then started in respect of their dependency information. Even if a
feature has no requirement with respect to start ordering of their bundles, it
has to define a start level (to act as a container for the bundles). It can use
any positive number, suggested is to use "1"
+
# Configurations belonging to Bundles
In most cases, configurations belong to a bundle. The most common use case is
a configuration for a (DS) component. Therefore instead of having a separate
configurations section, it is more intuitiv to specify configurations as part
of a bundle. The benefit of this approach is, that it can easily be decided if
a configuration is to be used: if exactly that bundle is used, the
configurations are used; otherwise they are not.
