Hi Thanks for the update.
A few months back I created this project: https://github.com/schaefa/sling-featuremodel-starter <https://github.com/schaefa/sling-featuremodel-starter> This project does take the existing Sling Provisioning Model and converts it into a FM and then launches it. This coming weekend I will update the project to the latest changes with respect to the Sling Feature Converter Maven Plugin and the Sling Feature Maven Plugin. Cheers - Andy > On Sep 5, 2019, at 8:20 AM, Stefan Seifert <[email protected]> wrote: > > 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:[email protected]] >> 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 <[email protected]> >> 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 >>> >> > >
