Re: [hackathon] switch to feature model

[Carsten Ziegeler]

In addition, we should - over time - transition away from the 
provisioning model to the better feature model. While the provisioning 
model did its job, the feature model has way more features and it also 
has a much better way to define OSGi configurations (using an OSGi 
standard).

As Stefan says, the feature model is a description - it is not tied in 
any way how this description is used. Nothing is preventing you from 
using it similar to the provisioning model and handle it dynamically at 
runtime.

Regards
Carsten

Am 05.09.2019 um 17:20 schrieb Stefan Seifert:
well, currently the sling starter is defined by the provisioning model, we just 
want to switch to the feature model.
the output will be basically the same, just the way to describe it changes.

using feature model alone does not imply that the instance is immutable or 
cannot be used to deploy new packages to it. this is only the case if you use 
it to setup a docker-like environment with a composite node store where the 
/libs and /apps folders are locked down and the rest is in a mongo persistence.

stefan

-----Original Message-----
From: Andreas Schaefer [mailto:schaef...@me.com.INVALID]
Sent: Thursday, September 5, 2019 4:31 PM
To: dev
Subject: Re: [hackathon] switch to feature model

Hi

I am not sure what the goals are when switching to FM?

As far as I understand it the FM should allow us to create an unmutable
Sling instance and an update is done by creating a new Sling instance that
is then deployed over the existing one keeping the user data repository
alive but replacing the rest aka no more package / bundle deployment.

Or is the FM just another way to build and install Sling, Packages and
Bundles?

Cheers - Andy

On Sep 5, 2019, at 7:10 AM, Stefan Seifert <sseif...@pro-vision.de>
wrote:

- yes, we want to switch - and soon, so it can be part of sling 12
- what the feature model tooling is currently missing is building a
combined jar file or WAR file
- for this it's planned to start with a "bridging solution", that means
generating a provisioning out of the feature models and build the combined
jar and WAR files from it
- it's still good to provide a combined jar file for non-docker use
cases, it's a counterpart to what sling boot provides as well
- for WAR file there still might be rare use cases as well

- granularity of the features defined: start with putting the whole sling
starter in a feature model, and later think about breaking it down to
smaller features
- note: feature model does not allow to define dependencies to other
features
- this does not allow to map the current list of karaf features directly
to sling features, as they are very finegrained and heavily rely on
features depending on features

- it would also be nice to habe an maven archetype which sets up a
feature model-based sling application project

stefan





--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org