well, currently the sling starter is defined by the provisioning model, we just want to switch to the feature model. the output will be basically the same, just the way to describe it changes.
using feature model alone does not imply that the instance is immutable or cannot be used to deploy new packages to it. this is only the case if you use it to setup a docker-like environment with a composite node store where the /libs and /apps folders are locked down and the rest is in a mongo persistence. stefan >-----Original Message----- >From: Andreas Schaefer [mailto:schaef...@me.com.INVALID] >Sent: Thursday, September 5, 2019 4:31 PM >To: dev >Subject: Re: [hackathon] switch to feature model > >Hi > >I am not sure what the goals are when switching to FM? > >As far as I understand it the FM should allow us to create an unmutable >Sling instance and an update is done by creating a new Sling instance that >is then deployed over the existing one keeping the user data repository >alive but replacing the rest aka no more package / bundle deployment. > >Or is the FM just another way to build and install Sling, Packages and >Bundles? > >Cheers - Andy > >> On Sep 5, 2019, at 7:10 AM, Stefan Seifert <sseif...@pro-vision.de> >wrote: >> >> - yes, we want to switch - and soon, so it can be part of sling 12 >> - what the feature model tooling is currently missing is building a >combined jar file or WAR file >> - for this it's planned to start with a "bridging solution", that means >generating a provisioning out of the feature models and build the combined >jar and WAR files from it >> - it's still good to provide a combined jar file for non-docker use >cases, it's a counterpart to what sling boot provides as well >> - for WAR file there still might be rare use cases as well >> >> - granularity of the features defined: start with putting the whole sling >starter in a feature model, and later think about breaking it down to >smaller features >> - note: feature model does not allow to define dependencies to other >features >> - this does not allow to map the current list of karaf features directly >to sling features, as they are very finegrained and heavily rely on >features depending on features >> >> - it would also be nice to habe an maven archetype which sets up a >feature model-based sling application project >> >> stefan >> >
