as some of you might already have seen or heard during adaptTo, the
whiteboard contains a new feature based model at  which is intended
to be a better provisioning model.
The repository at  contains a readme which details the reasons and is
a basic description of the approach. But I would like to give some
reasons why the provisioning model in its current form is not ideal.
The idea of a feature is to be the next higher level building block
above bundles. Its a collection of bundles with configurations (and
potentially other artifacts) that work together as a unit. For example,
the Sling scripting + HTL + Sling models could be a feature providing
all necessary building blocks for scripting. An application is then an
assembly of features.
These are some of the disadvantages of the provisioning model:
* Single file can contain more than one feature
* Custom DSL - no standard format (like JSON)
* Inheritance and custom artifacts (content packages) are mixed with
bundles, which makes processing and understanding more complicated
* Adding additional info to artifacts looks strange
* Two formats for configurations and now there is an official JSON based
format defined through OSGi R7
* Strange object relationship between feature and run modes
* API (object relation) differs from text file (to make the text format
* Tooling only available as maven plugins, not separate usable. So the
processing of the model is not described as part of the model
* Run mode handling is complicating the feature files and processing of
* Tightly coupled with the way Sling's launchpad works, therefore no
independent OSGi format
Especially the format of the description lead to start a new approach.
As mentioned above there is now a standard for OSGi configurations in
JSON and there were a lot of complaints that our current format is not
any standard format like JSON or YAML or even XML. If one part is
already JSON, then it makes sense to go with this for the whole format.
In addition there are more basic design criterias:
* A feature is a separate file with a required id and version
* A feature can include other features
* No support for run modes in the model - run modes can be modeled
through separate features
* Extension based approach for things like repoinit or content packages.
* Support OSGi requirements and capabilities for dependency handling
* Describe the processing of features as part of the model
* The description should be independent of how this is later on used,
e.g. a feature can be processed to create a Karaf Feature, a subsystem
or anything else.
The whiteboard contains a first implementation of the feature model
together with some additions:
An analyser and resolver framework which allows to analyse the model
whether all requirements are met and the application should be able to
run. So things like missing bundles (for package exports) can easily be
detected at run time. The resolver can be used to create a minimal
application. It gets a set of features as input that you want to run and
based on requirements and capabilities the resolver will add missing
pieces in the form of features.
Finally there is a launcher which is able to directly run a set of
features (or an application).
I understand that this is a lot of new stuff and some parts are not
completely implemented yet. But I wanted to have something running to
get a sense of feasability before starting a discussion. And now seems
to be a good time to do so.
The long goal is to have a feature model which potentially can have a
much broader use than just Sling. It's totally independent of Sling and
we could think about moving it to Apache Felix. Or Apache Karaf could
potentially replace their model with ours and we could try to make this
an OSGi standard. While imho these things make sense, they take time. In
addition if we can agree that this approach is the way to move forward
we should try to get rid of all other existing approaches and deprecated
them. So we only have one way of doing things.
For the naming, it currently runs under the name "Sling Feature". People
at adaptTo liked the name, but still if someone has an even better idea,
let's discuss it.
One minor thing, the current proposal uses the Maven coordinates to
describe artifacts. It's using the path part of a maven url, so
basically group id, artifact id, version are separated by a slash. It
seems that the notation of separating these things by a colon is more
common/natural. And we'll probably switch to that.
Feedback more than welcome.
Adobe Research Switzerland