I think we need a new approach to describe a deliverable or installation.
Right now we have the maven launchpad plugin which uses the bundle list xml
and a set of other files like configurations, properties files and
additional information in the pom. It would be great to have all the
information in a single place to make it more understandable but also to
allow for new ways of operations.
Therefore I came up with "slingstart" which at its core is a model (simple
java data objects) that describes an installation but also allows to
customize it. The central object of the model is callled a subsystem and
this consists of run modes and properties. The properties can be used for
variable substitution in the model.
A run mode is defined by names - at provisioning time, the corresponding
artifacts of the run mode are only applied - if all run modes defined by
the names are active. There is a default run mode which is always active.
Therefore this, at first, is pretty similar to the bundle list xml, but
reverted: instead of applying a run mode to an artifact, artifacts are
collected by a run mode. In a similar way start levels are supported.
However, in addition, a run mode can contain OSGi configurations and
settings, the settings are available as framework properties.
This gives a comprehensive model which contains all relevant information.
Furthermore, it defines special run modes, like :base (to define Sling's
launchpad artifact), :boot (to define all bootstrap artifacts available
before the framework starts), :standalone ( artifacts only for the
standalone jar), and :webapp (artifacts only for the webapp). Additional
special run modes can be defined by prefixing them with a colon. For
example it could be used to define all additional artifacts, settings and
configurations for integration testing.
This model is a small single java library which can be used by different
tooling. I've written a simple maven plugin which can be used as a
replacement for the maven launchpad plugin. But also, e.g. crankstart could
use this model, especially as it also describes how to merge two models. So
this can be used to define a base installation by one model, and operators
can define their operations model overlaying specific parts and then at
startup these are merged.
The model is not tied to any model language, I've added a simple XML
representation which is more compact than the bundle list. See example
below.
I think this gives a much nicer way of defining the deliverable with all
the different requirements, especially as it is extensible. In addition it
allows to override existing models in a well defined way and to merge
models. Models can be defined in any way, either a single model, or a
separate model for each run mode, each feature etc.
I would like to move to slingstart once we have Sling 7 out. The basic code
(the model api and the maven plugin are there and migration from the bundle
list is quiet easy)
Regards
Carsten
XML Sample:
<?xml version="1.0"?>
<subsystem>
<properties>
eventadmin.version=1.0.0
metatype.version=1.2.0
</properties>
<artifact groupId="org.apache.sling" artifactId="eventadmin"
version="${eventadmin.version}"/>
<artifact groupId="org.apache.sling" artifactId="metatype"
version="${metatype.version}"/>
<artifact groupId="org.apache.sling" artifactId="coordinator"
version="3.0.0"/>
<configuration pid="org.apache.sling.eventadmin">
useQueue=true
ignoreTopics=["myTopic"]
</configuration>
<runMode modes="mymode">
<artifact groupId="org.apache.sling" artifactId="metatype"
version="${metatype.version}"/>
<artifact groupId="org.apache.sling" artifactId="coordinator"
version="3.0.0"/>
<configuration pid="org.apache.sling.eventadmin">
useQueue=false
ignoreTopics=["myTopic", "test"]
</configuration>
<startLevel level="5">
<artifact groupId="org.apache.sling"
artifactId="eventadmin" version="${eventadmin.version}"/>
</startLevel>
</runMode>
</subsystem>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
