[hackathon] switch to feature model

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[hackathon] switch to feature model

Stefan Seifert
- 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

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Andreas Schaefer-5
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

RE: [hackathon] switch to feature model

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:[hidden email]]
>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 <[hidden email]>
>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
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Andreas Schaefer-5
Hi

Thanks for the update.

A few months back I created this project:

https://github.com/schaefa/sling-featuremodel-starter <https://github.com/schaefa/sling-featuremodel-starter>

This project does take the existing Sling Provisioning Model and converts it into a FM and then launches it.

This coming weekend I will update the project to the latest changes with respect to the Sling Feature Converter
Maven Plugin and the Sling Feature Maven Plugin.

Cheers - Andy

> On Sep 5, 2019, at 8:20 AM, Stefan Seifert <[hidden email]> wrote:
>
> 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:[hidden email]]
>> 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 <[hidden email]>
>> 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
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Carsten Ziegeler
In reply to this post by Stefan Seifert
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:[hidden email]]
>> 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 <[hidden email]>
>> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Robert Munteanu-2
In reply to this post by Stefan Seifert
On Thu, 2019-09-05 at 14:10 +0000, Stefan Seifert wrote:
> - it would also be nice to habe an maven archetype which sets up a
> feature model-based sling application project

Would this then be part of the sling-project-archetype? We could add a
new 'starter' or 'launcher' module to that archetype.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Andreas Schaefer-5
In reply to this post by Andreas Schaefer-5
I updated the my poor man’s version of the Sling Feature Model Starter project mentioned below.
It works now with the latest Sling Feature releases as well as the latest of CP Converter and the
Sling Feature Maven Converter Plugin (the last two must be built locally).

This project is not intended to become the FM Sling Starter project as this still uses the PMs as source.
It was just a way to get Sling started as FM to deal with issues.

Cheers - Andy

> On Sep 5, 2019, at 11:01 AM, Andreas Schaefer <[hidden email]> wrote:
>
> Hi
>
> Thanks for the update.
>
> A few months back I created this project:
>
> https://github.com/schaefa/sling-featuremodel-starter <https://github.com/schaefa/sling-featuremodel-starter>
>
> This project does take the existing Sling Provisioning Model and converts it into a FM and then launches it.
>
> This coming weekend I will update the project to the latest changes with respect to the Sling Feature Converter
> Maven Plugin and the Sling Feature Maven Plugin.
>
> Cheers - Andy
>
>> On Sep 5, 2019, at 8:20 AM, Stefan Seifert <[hidden email]> wrote:
>>
>> 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:[hidden email]]
>>> 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 <[hidden email]>
>>> 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
>>>>
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Andreas Schaefer-5
In reply to this post by Robert Munteanu-2
Hi

We for sure can look into that but I am wondering if we keep CP as they are right now and then convert them or if we move CPs to be FM based?

Cheers - Andy

> On Sep 6, 2019, at 6:11 AM, Robert Munteanu <[hidden email]> wrote:
>
> On Thu, 2019-09-05 at 14:10 +0000, Stefan Seifert wrote:
>> - it would also be nice to habe an maven archetype which sets up a
>> feature model-based sling application project
>
> Would this then be part of the sling-project-archetype? We could add a
> new 'starter' or 'launcher' module to that archetype.
>
> Robert
>

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Robert Munteanu-2
On Fri, 2019-09-06 at 14:57 -0700, Andreas Schaefer wrote:
> Hi
>
> We for sure can look into that but I am wondering if we keep CP as
> they are right now and then convert them or if we move CPs to be FM
> based?

Can we convert them if they have content that is not manageable via
repoinit instructions?

Thanks,
Robert

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Andreas Schaefer-5
Hi

I am not sure about this but my question was the other way around.

Do we want in the future that Content Package are writing in a Feature Model way (Content ZIP file separate from Bundles connected though a FM configuration)?

As far as I am concerned I do not see any issues where a traditional CP cannot be writing in an FM way but I might be wrong.

- Andy

> On Sep 9, 2019, at 2:33 AM, Robert Munteanu <[hidden email]> wrote:
>
> On Fri, 2019-09-06 at 14:57 -0700, Andreas Schaefer wrote:
>> Hi
>>
>> We for sure can look into that but I am wondering if we keep CP as
>> they are right now and then convert them or if we move CPs to be FM
>> based?
>
> Can we convert them if they have content that is not manageable via
> repoinit instructions?
>
> Thanks,
> Robert
>

Reply | Threaded
Open this post in threaded view
|

Re: [hackathon] switch to feature model

Robert Munteanu-2
On Mon, 2019-09-09 at 09:04 -0700, Andreas Schaefer wrote:

> Hi
>
> I am not sure about this but my question was the other way around.
>
> Do we want in the future that Content Package are writing in a
> Feature Model way (Content ZIP file separate from Bundles connected
> though a FM configuration)?
>
> As far as I am concerned I do not see any issues where a traditional
> CP cannot be writing in an FM way but I might be wrong.

So

current way = bundles embedded in content packages
feature model way = bundles declared in the feature model

?

I would go with the second option, but I don't think it's something to
invest too much effort into right now.

Thanks,
Robert