On Friday 30 September 2016 14:00:23 Carsten Ziegeler wrote: > Stefan Seifert wrote > > > discussed at the Sling Committer Round Table @ adaptTo() 2016 > > > > currently we have Slind launchpad with a quite monolithic configuration > > [1] one big list of all sling bundles), and we have a karaf feature > > repository [2] with nicely cut features for different aspects of sling, > > allowing the deployer to choose which sling features are wanted and which > > not, and which are the dependencies. oliver did today a talk on > > karaf/sling [3]. > > > > the launchpad should be split up in separates features/provisioning > > fragments to make it possible to easily build a "minimal launchpad" or > > "minimal launchpad + X" by selection only some but not all features. > > > > both launchpad features and karaf features should share a common source to > > avoid maintaining both in parallel. one could be generated from the > > other. > Atm the provisioning model has a slightly larger function set as karaf > features. We have support for framework properties and things like the > repo init stuff.
I don't think the feature set of Sling's provisioning model is larger but different. Karaf Features e.g. allow to define dependencies and OSGi requirements/capabilities or adding descriptions, see it's documentation[1] and XSD[2]. As Karaf Features evolve also I don't think it's that difficult to get support for framework properties or any other general requirement in. > The text based format is also easier to diff than XML. Tooling. > The OSGi alliance defines a YAML format for configurations which I would > like to directly support in the provisioning model (or whatever we use > as the source). > > And we have tooling like crankstart that can take a provisioning model > directly and launch the instance. > > This all leads me to the suggestion that we keep the provisioning model > and generate the karaf features xml out of this. As the provisioning > model supports features already we can directly create the features in > the launchpad provisioning model as they are currently defined for karaf. As long as we don't lose any (provisioning) features in Sling's Karaf Features and we always have a stable provisioning model (no snapshots, guaranteed set of working bundles) and a process which is 100% automated I'm fine with generating Karaf Features from Sling's provisioning model. Regards, O. [1] https://karaf.apache.org/manual/latest/#_provisioning [2] https://github.com/apache/karaf/blob/master/features/core/src/main/resources/org/apache/karaf/features/karaf-features-1.4.0.xsd > Regards > > Carsten
