sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Schaefer <>
Subject Re: [discuss] Migrating the Sling Starter to the Feature Model
Date Mon, 11 May 2020 20:43:32 GMT
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

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

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.

Cheers - Andy

> On May 11, 2020, at 1:05 PM, Robert Munteanu <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message