I think in general, this issue is a little bit more complex and actually consists of different issues. One of them is the other thread about "Sling Launchpad and Sling Karaf features".
So we have to separate the discussion about the format we use to define an instance (provisioning model vs karaf features xml), the other discussion is about the possibilities we provide to launch the instance. Launchpad is in direct competition with Karaf. However Launchpad does not add that much anymore to launching a framework. The start level handling and framework properties support are probably the only things in there. I personally don't see a reason why we should continue developing launchpad, if something existing - which is also used by the larger OSGi community - could be used instead. I don't know if Karaf has anything compared to crankstart, maybe there is or we could contribute it - which again would have a much larger outreach than Sling. Carsten Ian Boston wrote > Hi, > Did you discuss Crankstart provisioning models ? > They appear to extremely powerful way of defining many configurations, > storing them in SVN and running them without depending on some other > launchpad. The MoM integration tests under contrib use a provisioning model > to define a minimalist OSGi container. > I was under the impression that the Sling launchpad did many custom things, > not present in a generic OSGi container bootstrap. > Best Regards > Ian > > On 28 September 2016 at 22:39, Stefan Seifert <[email protected]> > wrote: > >> discussed at the Sling Committer Round Table @ adaptTo() 2016 >> >> one idea arised: why do we still maintain our own launchpad, when the >> "rest of the world" is using karaf? >> karaf is quite mature now, and no longer bloated or too complex as it may >> be some years ago. >> >> we did not go deeper into the details on this. >> >> stefan >> >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
