Sling Feature Model and RunModes

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

Sling Feature Model and RunModes

Björn Weide
Hi all,

I recently tried to create a simple OSGi (non-Sling) based app using the
Sling Feature Model. This works very well, but I was wondering about the
best way to simulate Sling Runmodes in such a setup (I somehow couldn't
find a hint on that in the current documentation of the Feature Model).

Currently I splitted the configuration of the app in a global feature and a
couple of environment-specific ones. I deployed all configurations into the
repository and then started the app with multiple feature files given (one
defining the server - bundles and server configuration, one containing the
global app configuration and one for the respective environment-specific
configuration).

This approach works, but I was wondering how to build the artifacts
correctly. I placed all configurations in a dedicated Maven module and
wanted to generate a feature per environment so that all config features
have the same group/artifact but individual classifiers. My structure
looked like this
- global.json = global app configuration feature
- production.json = env-specific configuration feature for "production"
runmode
- test.json = another env-specific configuration feature for "test" runmode

Unfortunately it couldn't figure out how to generate a feature from a given
feature file with a given classifier only - not sure if this is supported.
I got my setup working by only aggregate a feature with the global.json
feature file - the other 2 feature files were automatically generated
during the build with the classifier = filename. So this nicely worked, but
I am not sure if this is a bug or a feature.

What would be the correct approach for such a setup?

Best regards,
Bjoern
Reply | Threaded
Open this post in threaded view
|

Re: Sling Feature Model and RunModes

Carsten Ziegeler
Hi,

you can do this by using the slingfeature maven plugin and creating an
aggregate per environment.
https://github.com/apache/sling-slingfeature-maven-plugin#aggregate-features

For each aggregate you create you choose a new classifier name and list
the classifiers of the features you want to include.

Regards
Carsten

Am 29.10.2019 um 18:10 schrieb Björn Weide:

> Hi all,
>
> I recently tried to create a simple OSGi (non-Sling) based app using the
> Sling Feature Model. This works very well, but I was wondering about the
> best way to simulate Sling Runmodes in such a setup (I somehow couldn't
> find a hint on that in the current documentation of the Feature Model).
>
> Currently I splitted the configuration of the app in a global feature and a
> couple of environment-specific ones. I deployed all configurations into the
> repository and then started the app with multiple feature files given (one
> defining the server - bundles and server configuration, one containing the
> global app configuration and one for the respective environment-specific
> configuration).
>
> This approach works, but I was wondering how to build the artifacts
> correctly. I placed all configurations in a dedicated Maven module and
> wanted to generate a feature per environment so that all config features
> have the same group/artifact but individual classifiers. My structure
> looked like this
> - global.json = global app configuration feature
> - production.json = env-specific configuration feature for "production"
> runmode
> - test.json = another env-specific configuration feature for "test" runmode
>
> Unfortunately it couldn't figure out how to generate a feature from a given
> feature file with a given classifier only - not sure if this is supported.
> I got my setup working by only aggregate a feature with the global.json
> feature file - the other 2 feature files were automatically generated
> during the build with the classifier = filename. So this nicely worked, but
> I am not sure if this is a bug or a feature.
>
> What would be the correct approach for such a setup?
>
> Best regards,
> Bjoern
>

--
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Sling Feature Model and RunModes

Björn Weide
Hi Carsten,

after investigating a bit further I can confirm that this works just fine!
The only issue I ran into was the mentioned behavior of the plugin to
extract all feature files into a flat tmp folder and then auto-generate a
classifier per filename, which sometimes leads to unexpected collisions.

For example when manually defining an aggregate with a "prod" classifier
referencing a file named "prod" as well this will fail with an error like
"More than one feature file for classifier prod in project". Do you think
this should be treated as bug? Or is this a special reason for this
behavior (in that case I think it would be good to mention this in the
documentation).

Thanks a lot and best regards,
Bjoern

On 30 October 2019 at 18:00:51, Carsten Ziegeler ([hidden email])
wrote:

Hi,

you can do this by using the slingfeature maven plugin and creating an
aggregate per environment.
https://github.com/apache/sling-slingfeature-maven-plugin#aggregate-features

For each aggregate you create you choose a new classifier name and list
the classifiers of the features you want to include.

Regards
Carsten

Am 29.10.2019 um 18:10 schrieb Björn Weide:
> Hi all,
>
> I recently tried to create a simple OSGi (non-Sling) based app using the
> Sling Feature Model. This works very well, but I was wondering about the
> best way to simulate Sling Runmodes in such a setup (I somehow couldn't
> find a hint on that in the current documentation of the Feature Model).
>
> Currently I splitted the configuration of the app in a global feature and
a
> couple of environment-specific ones. I deployed all configurations into
the
> repository and then started the app with multiple feature files given
(one
> defining the server - bundles and server configuration, one containing
the

> global app configuration and one for the respective environment-specific
> configuration).
>
> This approach works, but I was wondering how to build the artifacts
> correctly. I placed all configurations in a dedicated Maven module and
> wanted to generate a feature per environment so that all config features
> have the same group/artifact but individual classifiers. My structure
> looked like this
> - global.json = global app configuration feature
> - production.json = env-specific configuration feature for "production"
> runmode
> - test.json = another env-specific configuration feature for "test"
runmode
>
> Unfortunately it couldn't figure out how to generate a feature from a
given
> feature file with a given classifier only - not sure if this is
supported.
> I got my setup working by only aggregate a feature with the global.json
> feature file - the other 2 feature files were automatically generated
> during the build with the classifier = filename. So this nicely worked,
but
> I am not sure if this is a bug or a feature.
>
> What would be the correct approach for such a setup?
>
> Best regards,
> Bjoern
>

--
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Sling Feature Model and RunModes

Carsten Ziegeler
Hi Bjoern

yes, this is a special feature :) With it you don't have to define the
feature ID in the feature file itself, it just gets auto generated based
on the coordiantes of the maven project and the file name used as qualifier.
If you want to use a different qualifier than the file name then you can
encode the full id in your feature file.

Thanks for mentioning this, its definitely something thats missing in
the docs. I'll update them later today

Regards
Carsten

Am 04.11.2019 um 09:33 schrieb Björn Weide:

> Hi Carsten,
>
> after investigating a bit further I can confirm that this works just fine!
> The only issue I ran into was the mentioned behavior of the plugin to
> extract all feature files into a flat tmp folder and then auto-generate a
> classifier per filename, which sometimes leads to unexpected collisions.
>
> For example when manually defining an aggregate with a "prod" classifier
> referencing a file named "prod" as well this will fail with an error like
> "More than one feature file for classifier prod in project". Do you think
> this should be treated as bug? Or is this a special reason for this
> behavior (in that case I think it would be good to mention this in the
> documentation).
>
> Thanks a lot and best regards,
> Bjoern
>
> On 30 October 2019 at 18:00:51, Carsten Ziegeler ([hidden email])
> wrote:
>
> Hi,
>
> you can do this by using the slingfeature maven plugin and creating an
> aggregate per environment.
> https://github.com/apache/sling-slingfeature-maven-plugin#aggregate-features
>
> For each aggregate you create you choose a new classifier name and list
> the classifiers of the features you want to include.
>
> Regards
> Carsten
>
> Am 29.10.2019 um 18:10 schrieb Björn Weide:
>> Hi all,
>>
>> I recently tried to create a simple OSGi (non-Sling) based app using the
>> Sling Feature Model. This works very well, but I was wondering about the
>> best way to simulate Sling Runmodes in such a setup (I somehow couldn't
>> find a hint on that in the current documentation of the Feature Model).
>>
>> Currently I splitted the configuration of the app in a global feature and
> a
>> couple of environment-specific ones. I deployed all configurations into
> the
>> repository and then started the app with multiple feature files given
> (one
>> defining the server - bundles and server configuration, one containing
> the
>> global app configuration and one for the respective environment-specific
>> configuration).
>>
>> This approach works, but I was wondering how to build the artifacts
>> correctly. I placed all configurations in a dedicated Maven module and
>> wanted to generate a feature per environment so that all config features
>> have the same group/artifact but individual classifiers. My structure
>> looked like this
>> - global.json = global app configuration feature
>> - production.json = env-specific configuration feature for "production"
>> runmode
>> - test.json = another env-specific configuration feature for "test"
> runmode
>>
>> Unfortunately it couldn't figure out how to generate a feature from a
> given
>> feature file with a given classifier only - not sure if this is
> supported.
>> I got my setup working by only aggregate a feature with the global.json
>> feature file - the other 2 feature files were automatically generated
>> during the build with the classifier = filename. So this nicely worked,
> but
>> I am not sure if this is a bug or a feature.
>>
>> What would be the correct approach for such a setup?
>>
>> Best regards,
>> Bjoern
>>
>

--
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]