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 <[email protected]> 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
> [email protected]
>
