Right, the proposed idea does not invalidate the usefulness of the kickstart project. I think they are complementary. Feature archives allow to distribute a complete feature without requiring any additional infrastructure (like a maven repository)


On 25.03.2020 19:12, Andreas Schaefer wrote:

There is a Sling Feature Starter 
<https://github.com/apache/sling-org-apache-sling-kickstart>) as well as a Maven 
Plugin that provides the ability to launch the Sling Feature Starter as a Maven Goal 

That said we can add the support for Feature Archives to prevent the downloads 
of all the features during launch but we should support both approaches as the 
download path allows to run the latest.

Cheers - Andy

On Mar 25, 2020, at 2:21 AM, Carsten Ziegeler <cziege...@apache.org> wrote:


our current Sling starter project is still using the provisioning model. It 
creates a startable jar and a webapp out of it.

Moving forward we want to switch to the feature model.

We already discussed in previous discussion that supporting a webapp is not 
necessary. If demanded by users it can still be done at a later step.

Migrating from the provisioning model to the feature model is one thing and 
that's more or less straight forward.

But the more interesting question is what we do for the starter. If we do the 
same as is available today, we could build a simple maven plugin which 
basically creates a jar file containing the feature launcher, the OSGi 
framework and the features and its artifacts with some code to extract this and 
start it.

While this is very convenient - you get a single jar with everything and can 
just run it - it comes with the downside of bundling everything together. So 
using a newer launcher, a newer framework etc. always requires updating the 
Starter project.

On the other hand, we have the concept of feature archives: a zip file with 
features and its artifacts. This can be used for distributing features up to 
complete applications, like the starter. So another option is to just create a 
feature archive of the starter and then users can use a launcher to launch it. 
This is not as user friendly but makes it easier to update the launcher, the 
framework etc. And also comes with the bonus that its easy to add additional 
features to the launch.

In any case, we should probably add support to the feature launcher to launch 
feature archives directly - regardless of what we do with the starter. That's a 
minor addition to the launcher rounding up our tooling story about features.

Add this point I'm a little bit unsure which way to go with the starter, 
therefore asking for feedback. I'm currently leaning towards the second option: 
just creating a feature archive for the starter (which we can already do today)



Carsten Ziegeler
Adobe Research Switzerland

Carsten Ziegeler
Adobe Research Switzerland

Reply via email to