Hi, as some of you might already have seen or heard during adaptTo, the whiteboard contains a new feature based model at [1] which is intended to be a better provisioning model.
The repository at [1] 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 easier) * 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 those * 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. [1] https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/feature/ Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
