Hi, our launchpad is currently based on the (old) bundle list format. Additional input that gets into the launchpad is split across different places, like configurations in specific directories, framework properties in some property files etc.
Some time ago we developed the provisioning model which is a nicer format to define all these things in one place. So instead of looking at various places, you have a single place to go. Examples for the model can be found here: http://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/provisioning/ As you can see in that example, it is possible to split the model into several files, but that's not required. The model files are also much easier to diff as e.g. an artifact definition is in one line. While with the XML format you see that version 1.0.0 changed to 1.0.1 and you have no clue which artifact that is (unless you have context lines), with the provisioning model you see which artifact changed the version. At Adobe we're using the provisioning model for some time now and it made things easier and is much more appreciated than the old approach. Alright, to keep a long story short, I think it would make sense for Sling to switch to the new model and forget about the old approach. The slingstart-maven-plugin is a replacement of the launchpad plugin and does the same, but just based on the model. The maven plugin is a clean implementation which also builds the launchpad much faster :) Ok, so where are the problems with switching? The slingstart plugin does not provide all features, it can just build the launchpad. All other features are missing. So, wdyt should we switch? What do we do with the missing features? Do we implement them after the switch as needed? Which ones do we really need? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
