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 <cziege...@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 > cziege...@apache.org >