HI There is a Sling Feature Starter (https://github.com/apache/sling-org-apache-sling-kickstart <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 (https://github.com/apache/sling-kickstart-maven-plugin <https://github.com/apache/sling-kickstart-maven-plugin>).
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: > > Hi, > > 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) > > WDYT? > > > Regards > Carsten > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
