Hi Andy, On Mon, 2020-05-11 at 09:50 -0700, Andreas Schaefer wrote: > Hi Robert > > Thanks for the nice rundown here but I think it is slightly "behind > the curve”. > > The current Kickstart project will: > - take the Provisioning Model (PM) files and convert them into a > Feature Model (FM) files > - aggregates the FM files into a single FM (feature-sling12.json) > - launches the Sling with the Feature Launcher with the feature- > sling12.json > - has the ability to launch Sling12 with a FAR file if provided > - run Sling in the background as a service (if needed) (-s option) > - can obtains status and stop a launched instance > - add additional FMs (custom projects) to the launch (-af option)
Right, the kickstart project is quite featureful, and I personally see it as a 'batteries-included' launcher, which goes beyond what the 'stock' feature launcher offers. There are scenarios where kickstart is better suited, and scenarios where the additional complexity is not needed. (Hindsight being 20/20 and all, I'd have suggested 'thinpad' as the name for it, as I currently see it as a replacement for the launchpad, but thinner). > Right now this is only tested for oak_tar but there it works like a > charm. > > Down the road I would like the Kickstart to be able to launch Sling > with a composite node store (read-only libs, writable content) w/o > any user interaction. > > From my point of view the coding part of Phase 1 and 2 is mostly > done. > > These are the next step I see: > - add support for analyzer (when I created Kickstart the analyzer was > not working properly so I took it out) > - test Kickstart with oak_mongo > - add composite node-store support to Kickstart > - migrate Sling Modules to creating FMs > - aggregating Sling based on FMs directly (no PMs involved) > - lots and lots of documentation Here is where I see an overlap with the feature model tooling. We have analysers, aggregators, launchers, etc in the feature model as standalone applications, java libraries and Maven plug-ins. I think it makes sense to have each tool with its own well-defined purpose. I definitely see the value in having a full-fledged replacement for the launchapd - that is the kickstart. However, it would be confusing to have the same functionality defined in both the feature and the kickstart plugins, and while I don't claim to be the hardest person to confuse :-) I think that this confusion would apply to our users as well. I believe that the kickstart should focus on being an advanced launcher, while the feature tooling providers the core services. This is why I suggested that we adopt the kickstart as a part of the feature build - the rest should be supported by the other feature-based tooling. > > In my view each Sling Module should create their own FM that includes > all the configurations (Service User Mappings etc) and the repoinit > it needs to run properly. (snip) I don't necessarily disagree, but let's please split this off into a different discussion. I think the 'in-place' conversion of the Starter is a large enough topic for now. Thanks, Robert
