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 <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
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
