You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Björn Weide <bj...@netcentric.biz> on 2019/10/29 17:10:12 UTC
Sling Feature Model and RunModes
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
Re: Sling Feature Model and RunModes
Posted by Carsten Ziegeler <cz...@apache.org>.
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 (cziegeler@apache.org)
> 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
cziegeler@apache.org
Re: Sling Feature Model and RunModes
Posted by Björn Weide <bj...@netcentric.biz>.
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 (cziegeler@apache.org)
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
cziegeler@apache.org
Re: Sling Feature Model and RunModes
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org