On Mon, 2020-05-11 at 14:34 -0700, Andreas Schaefer wrote: > Yes, that sums it up pretty much.
Great! > > Also the Kickstart is replacing Launchpad more than the SlingStarter > as the PMs go to the wayside in favor of the FMs that are then > managed outside of the Kickstart. Ack, fully agree on that. > > With that said the testing of Sling FM should be done in a new module > (Kickstart Testing?) than re-using Launchpad Testing but that seems > to be pretty straight forward as we can use Kickstart Plugin and the > converted Sling FM. Not sure about that. The direction we're heading towards is that Launchpad testing should be going away and the test launcher folded in the starter. The reasoning is that integration tests in the same module have a much higher chance of catching regressions early. But then again I think we should keep this out of scope and focus on the conversion itself [1]. > > For me the basics on how to convert Sling to FMs from PMs and how to > launch it is pretty much laid out. The next part is: > > - Create native Sling Module FMs > - Aggregate them into a Sling FM / FAR > - Adjust testing > - Write documentation > - Composite Nodestore +1 from me. Also the composite nodestore is a great feature to have set up. I would still like to focus on the feature model first, and then on the niceties :-) Regarding the feasibility of using the feature model tooling directly, I was able to tweak your great work from the kickstart and add an 'on- the-fly' conversion to the Sling Starter, so that the oak_tar aggregate is packaged. [2] Proof-of-concept to support the discussion, not necessarily the way we will go, so it's on a branch for now. Thanks, Robert [1]: https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model#MigratingtheSlingStartertotheFeatureModel-Outofscope [2]: https://github.com/apache/sling-org-apache-sling-starter/compare/feature/create-feature-aggregate?expand=1 > > - Andy > > > On May 11, 2020, at 2:07 PM, Robert Munteanu <romb...@apache.org> > > wrote: > > > > On Mon, 2020-05-11 at 13:43 -0700, Andreas Schaefer wrote: > > > Hi Robert > > > > > > I think there is a misconception what the Kickstart is. Here is > > > my > > > rundown: > > > > > > - Provides a Sling FM > > > - Creates a Control Thread > > > - Offers Sling specific CLI options and converts them to Sling > > > properties > > > - Launches Sling through the Feature Launcher > > > - Provides the ability to access Sling running in another thread > > > > > > Because of the current situation it also does that: > > > > > > - Provides a mean to convert Sling PMs to FMs > > > - Aggregates these FMs > > > > Ack. > > > > > That said this is just temporary and should go away as soon as > > > Sling > > > is Feature Model-yfied. > > > > > > I am not sure how Sling is used in production environments > > > (beside > > > Peregrine) but I assume customers use Sling Start one way the > > > other > > > even if they create their own PM(s) to launch it with the Starter > > > (Peregrine does that). > > > The Kickstart can take a custom Sling FM (override the packaged > > > one) > > > as well as custom project FM(s). > > > > > > As a user I do not want to hunt down the properties on how to > > > launch > > > Sling but rather have an option in a Start (here Kickstart). > > > Instead of “-Dsling.port=8080” something like “-p 8080” would be > > > better especially because the Kickstart expose these options with > > > the > > > “—help”” option. > > > > > > The Kickstart project does not compete or shadow any of the > > > feature > > > tooling but rather leverages them. In addition support for > > > Composite > > > Nodestores is something the Feature Launcher cannot do and would > > > require scripts to run which are harder to manage for an admin. > > > > Right. > > > > I get the feeling that I am missing something, as I think we write > > the > > same things but don't necessarily agree :-) > > > > Let me try and rephrase my draft proposal in a very compact manner, > > let's see where the difference lie. > > > > 1. The feature model provides tooling for assembling and validating > > feature model files. > > > > 2. Kickstart is a convenient, featureful high-level launcher, and > > some > > (most?) users will like to use that for starting Sling. > > > > 3. The feature model launcher is a pure OSGi launcher for users > > that > > either desire to not be tied to the kickstart or do not have an use > > for > > the additional features of the kickstart. > > > > Does that match how you see things? If not, I'd love to understand > > where things don't align. > > > > Thanks, > > Robert > > > Cheers - Andy > > > > > > > On May 11, 2020, at 1:05 PM, Robert Munteanu < > > > > romb...@apache.org> > > > > wrote: > > > > > > > > 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
