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)
Regards
Carsten
On 25.03.2020 19:12, Andreas Schaefer wrote:
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
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
