You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by David Bosschaert <da...@gmail.com> on 2018/11/07 16:46:05 UTC
Parameterizing Sling Feature model extensions
Hi all,
I would like to be able to send some parameters to my Feature Model
PostProcessHandler when its run from the slingfeature-maven-plugin. The
handlers in the org.apache.sling.feature.extension.apiregions component
generate files for the runtime component. I would like to be able to
configure where these files are written out so that I can later use them.
I was wondering what would be the best way to pass configuration to a
PostProcessHandler from the slingfeature-maven-plugin? There is already the
HandlerContext class passed to the handler, so maybe we can expand that
with a configuration map? Maybe as an extra tag in the <aggregate> section:
<aggregate>
<classifier/>
<title/>
<description/>
<markAsFinal/>
<filesInclude/>
<filesExclude/>
<includeArtifact/>
<includeClassifier/>
<handlerConfig> <!-- something like this one? -->
<myKey>myvalue</myKey>
</handlerConfig>
</aggregate>
Best regards,
David
Re: Parameterizing Sling Feature model extensions
Posted by Carsten Ziegeler <cz...@apache.org>.
lgtm
THanks
Carsten
Am 09.11.2018 um 17:37 schrieb David Bosschaert:
> Hi all,
>
> Looking at how this is now done for the analyse-features mojo [1], I would
> propose to follow a similar pattern for the extension handlers/post
> processors. We can add an optional handlerConfiguration tag in the
> aggregate-features task that holds configuration for specific handlers. As
> the key I would suggest to use the class name of the handler, although we
> could add a getId() method like is done with the Analyser Tasks.
>
> Something like this:
> <execution>
> <id>aggregate-my-feature</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>aggregate-features</goal>
> </goals>
> <configuration>
> <aggregates>
> <directory>
> <includes>*.json</includes>
> </directory>
> </aggregates>
> <handlerConfiguration>
> <BundleArtifactFeatureHandler>
>
> <fileStorage>${project.build.directory}/somedirectory</fileStorage>
> </BundleArtifactFeatureHandler>
> </handlerConfiguration>
> </configuration>
>
> Thoughts anyone?
>
> Best regards,
>
> David
>
> [1]
> https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/README.md#analyse-features
>
>
> On Thu, 8 Nov 2018 at 06:08, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> Rethinking my own proposal from below, I think it's mixing the concern
>> of how to configure it in a maven plugin with how to handle it in the
>> respective component. So instead of doing the filtering in the
>> component, I guess it makes more sense to let the caller do this.
>> Or in other words instead of passing a map with string keys and string
>> values in the below described format, we should rather pass a map with
>> string keys and a Properties object as the value, something like:
>> mytask={
>> foo=one
>> hi=hello
>> }
>> nexttask={
>> bla=two
>> }
>> *={
>> debug=true
>> }
>>
>> And we use the special key "*" for parameters passed to all components.
>>
>> Regards
>> Carsten
>>
>> Am 07.11.2018 um 18:49 schrieb Carsten Ziegeler:
>>> Hi,
>>>
>>> we're currently discussing a similar problem for SLING-8078 with Simo.
>>> So maybe we can have a similar approach here (at least for how this is
>>> configured in the plugin configuration).
>>>
>>> I'm fine to extend the HandlerContext to provide configuration
>>> properties. I guess we should plan for clashes in the names of those
>>> properties between the handlers.
>>>
>>> In the above mentioned issue we have a similar problem where
>>> configuration is passed to tasks. In that case each task has a name and
>>> the configuration map will contain keys in the form of
>>> "taskname_propertyname". When the actually configuration is passed down
>>> to the task, this map will be filtered and only properties without a
>>> prefix or with the right prefix will be passed. And that prefixed is
>>> removed.
>>>
>>> For example if these parameters are passed from the plugin
>>> mytask_foo=one
>>> mytask_hi=hello
>>> nexttask_bla=two
>>> debug=true
>>>
>>> and the task named "mytask" is invoked, the following paramters are
>>> available through the context to that task:
>>> foo=one
>>> hi=hello
>>> debug=true
>>>
>>> And then we have two types of handlers in your case, the
>>> PostProcessHandler and the MergeHandler. Do we need to distinguish
>>> between those when it comes to configuration?
>>>
>>> Regards
>>> Carsten
>>>
>>> Am 07.11.2018 um 17:46 schrieb David Bosschaert:
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I would like to be able to send some parameters to my Feature Model
>>>> PostProcessHandler when its run from the slingfeature-maven-plugin. The
>>>> handlers in the org.apache.sling.feature.extension.apiregions component
>>>> generate files for the runtime component. I would like to be able to
>>>> configure where these files are written out so that I can later use
>> them.
>>>>
>>>>
>>>> I was wondering what would be the best way to pass configuration to a
>>>> PostProcessHandler from the slingfeature-maven-plugin? There is
>>>> already the
>>>> HandlerContext class passed to the handler, so maybe we can expand that
>>>> with a configuration map? Maybe as an extra tag in the <aggregate>
>>>> section:
>>>>
>>>>
>>>> <aggregate>
>>>>
>>>> <classifier/>
>>>>
>>>> <title/>
>>>>
>>>> <description/>
>>>>
>>>> <markAsFinal/>
>>>>
>>>> <filesInclude/>
>>>>
>>>> <filesExclude/>
>>>>
>>>> <includeArtifact/>
>>>>
>>>> <includeClassifier/>
>>>>
>>>> <handlerConfig> <!-- something like this one? -->
>>>>
>>>> <myKey>myvalue</myKey>
>>>>
>>>> </handlerConfig>
>>>>
>>>> </aggregate>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> David
>>>>
>>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Parameterizing Sling Feature model extensions
Posted by David Bosschaert <da...@gmail.com>.
Hi all,
Looking at how this is now done for the analyse-features mojo [1], I would
propose to follow a similar pattern for the extension handlers/post
processors. We can add an optional handlerConfiguration tag in the
aggregate-features task that holds configuration for specific handlers. As
the key I would suggest to use the class name of the handler, although we
could add a getId() method like is done with the Analyser Tasks.
Something like this:
<execution>
<id>aggregate-my-feature</id>
<phase>generate-resources</phase>
<goals>
<goal>aggregate-features</goal>
</goals>
<configuration>
<aggregates>
<directory>
<includes>*.json</includes>
</directory>
</aggregates>
<handlerConfiguration>
<BundleArtifactFeatureHandler>
<fileStorage>${project.build.directory}/somedirectory</fileStorage>
</BundleArtifactFeatureHandler>
</handlerConfiguration>
</configuration>
Thoughts anyone?
Best regards,
David
[1]
https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/README.md#analyse-features
On Thu, 8 Nov 2018 at 06:08, Carsten Ziegeler <cz...@apache.org> wrote:
> Rethinking my own proposal from below, I think it's mixing the concern
> of how to configure it in a maven plugin with how to handle it in the
> respective component. So instead of doing the filtering in the
> component, I guess it makes more sense to let the caller do this.
> Or in other words instead of passing a map with string keys and string
> values in the below described format, we should rather pass a map with
> string keys and a Properties object as the value, something like:
> mytask={
> foo=one
> hi=hello
> }
> nexttask={
> bla=two
> }
> *={
> debug=true
> }
>
> And we use the special key "*" for parameters passed to all components.
>
> Regards
> Carsten
>
> Am 07.11.2018 um 18:49 schrieb Carsten Ziegeler:
> > Hi,
> >
> > we're currently discussing a similar problem for SLING-8078 with Simo.
> > So maybe we can have a similar approach here (at least for how this is
> > configured in the plugin configuration).
> >
> > I'm fine to extend the HandlerContext to provide configuration
> > properties. I guess we should plan for clashes in the names of those
> > properties between the handlers.
> >
> > In the above mentioned issue we have a similar problem where
> > configuration is passed to tasks. In that case each task has a name and
> > the configuration map will contain keys in the form of
> > "taskname_propertyname". When the actually configuration is passed down
> > to the task, this map will be filtered and only properties without a
> > prefix or with the right prefix will be passed. And that prefixed is
> > removed.
> >
> > For example if these parameters are passed from the plugin
> > mytask_foo=one
> > mytask_hi=hello
> > nexttask_bla=two
> > debug=true
> >
> > and the task named "mytask" is invoked, the following paramters are
> > available through the context to that task:
> > foo=one
> > hi=hello
> > debug=true
> >
> > And then we have two types of handlers in your case, the
> > PostProcessHandler and the MergeHandler. Do we need to distinguish
> > between those when it comes to configuration?
> >
> > Regards
> > Carsten
> >
> > Am 07.11.2018 um 17:46 schrieb David Bosschaert:
> >> Hi all,
> >>
> >>
> >>
> >> I would like to be able to send some parameters to my Feature Model
> >> PostProcessHandler when its run from the slingfeature-maven-plugin. The
> >> handlers in the org.apache.sling.feature.extension.apiregions component
> >> generate files for the runtime component. I would like to be able to
> >> configure where these files are written out so that I can later use
> them.
> >>
> >>
> >> I was wondering what would be the best way to pass configuration to a
> >> PostProcessHandler from the slingfeature-maven-plugin? There is
> >> already the
> >> HandlerContext class passed to the handler, so maybe we can expand that
> >> with a configuration map? Maybe as an extra tag in the <aggregate>
> >> section:
> >>
> >>
> >> <aggregate>
> >>
> >> <classifier/>
> >>
> >> <title/>
> >>
> >> <description/>
> >>
> >> <markAsFinal/>
> >>
> >> <filesInclude/>
> >>
> >> <filesExclude/>
> >>
> >> <includeArtifact/>
> >>
> >> <includeClassifier/>
> >>
> >> <handlerConfig> <!-- something like this one? -->
> >>
> >> <myKey>myvalue</myKey>
> >>
> >> </handlerConfig>
> >>
> >> </aggregate>
> >>
> >>
> >> Best regards,
> >>
> >>
> >> David
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
Re: Parameterizing Sling Feature model extensions
Posted by Carsten Ziegeler <cz...@apache.org>.
Rethinking my own proposal from below, I think it's mixing the concern
of how to configure it in a maven plugin with how to handle it in the
respective component. So instead of doing the filtering in the
component, I guess it makes more sense to let the caller do this.
Or in other words instead of passing a map with string keys and string
values in the below described format, we should rather pass a map with
string keys and a Properties object as the value, something like:
mytask={
foo=one
hi=hello
}
nexttask={
bla=two
}
*={
debug=true
}
And we use the special key "*" for parameters passed to all components.
Regards
Carsten
Am 07.11.2018 um 18:49 schrieb Carsten Ziegeler:
> Hi,
>
> we're currently discussing a similar problem for SLING-8078 with Simo.
> So maybe we can have a similar approach here (at least for how this is
> configured in the plugin configuration).
>
> I'm fine to extend the HandlerContext to provide configuration
> properties. I guess we should plan for clashes in the names of those
> properties between the handlers.
>
> In the above mentioned issue we have a similar problem where
> configuration is passed to tasks. In that case each task has a name and
> the configuration map will contain keys in the form of
> "taskname_propertyname". When the actually configuration is passed down
> to the task, this map will be filtered and only properties without a
> prefix or with the right prefix will be passed. And that prefixed is
> removed.
>
> For example if these parameters are passed from the plugin
> mytask_foo=one
> mytask_hi=hello
> nexttask_bla=two
> debug=true
>
> and the task named "mytask" is invoked, the following paramters are
> available through the context to that task:
> foo=one
> hi=hello
> debug=true
>
> And then we have two types of handlers in your case, the
> PostProcessHandler and the MergeHandler. Do we need to distinguish
> between those when it comes to configuration?
>
> Regards
> Carsten
>
> Am 07.11.2018 um 17:46 schrieb David Bosschaert:
>> Hi all,
>>
>>
>>
>> I would like to be able to send some parameters to my Feature Model
>> PostProcessHandler when its run from the slingfeature-maven-plugin. The
>> handlers in the org.apache.sling.feature.extension.apiregions component
>> generate files for the runtime component. I would like to be able to
>> configure where these files are written out so that I can later use them.
>>
>>
>> I was wondering what would be the best way to pass configuration to a
>> PostProcessHandler from the slingfeature-maven-plugin? There is
>> already the
>> HandlerContext class passed to the handler, so maybe we can expand that
>> with a configuration map? Maybe as an extra tag in the <aggregate>
>> section:
>>
>>
>> <aggregate>
>>
>> <classifier/>
>>
>> <title/>
>>
>> <description/>
>>
>> <markAsFinal/>
>>
>> <filesInclude/>
>>
>> <filesExclude/>
>>
>> <includeArtifact/>
>>
>> <includeClassifier/>
>>
>> <handlerConfig> <!-- something like this one? -->
>>
>> <myKey>myvalue</myKey>
>>
>> </handlerConfig>
>>
>> </aggregate>
>>
>>
>> Best regards,
>>
>>
>> David
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Parameterizing Sling Feature model extensions
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
we're currently discussing a similar problem for SLING-8078 with Simo.
So maybe we can have a similar approach here (at least for how this is
configured in the plugin configuration).
I'm fine to extend the HandlerContext to provide configuration
properties. I guess we should plan for clashes in the names of those
properties between the handlers.
In the above mentioned issue we have a similar problem where
configuration is passed to tasks. In that case each task has a name and
the configuration map will contain keys in the form of
"taskname_propertyname". When the actually configuration is passed down
to the task, this map will be filtered and only properties without a
prefix or with the right prefix will be passed. And that prefixed is
removed.
For example if these parameters are passed from the plugin
mytask_foo=one
mytask_hi=hello
nexttask_bla=two
debug=true
and the task named "mytask" is invoked, the following paramters are
available through the context to that task:
foo=one
hi=hello
debug=true
And then we have two types of handlers in your case, the
PostProcessHandler and the MergeHandler. Do we need to distinguish
between those when it comes to configuration?
Regards
Carsten
Am 07.11.2018 um 17:46 schrieb David Bosschaert:
> Hi all,
>
>
>
> I would like to be able to send some parameters to my Feature Model
> PostProcessHandler when its run from the slingfeature-maven-plugin. The
> handlers in the org.apache.sling.feature.extension.apiregions component
> generate files for the runtime component. I would like to be able to
> configure where these files are written out so that I can later use them.
>
>
> I was wondering what would be the best way to pass configuration to a
> PostProcessHandler from the slingfeature-maven-plugin? There is already the
> HandlerContext class passed to the handler, so maybe we can expand that
> with a configuration map? Maybe as an extra tag in the <aggregate> section:
>
>
> <aggregate>
>
> <classifier/>
>
> <title/>
>
> <description/>
>
> <markAsFinal/>
>
> <filesInclude/>
>
> <filesExclude/>
>
> <includeArtifact/>
>
> <includeClassifier/>
>
> <handlerConfig> <!-- something like this one? -->
>
> <myKey>myvalue</myKey>
>
> </handlerConfig>
>
> </aggregate>
>
>
> Best regards,
>
>
> David
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org