[ https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677823#comment-16677823 ]
Carsten Ziegeler edited comment on SLING-8058 at 11/7/18 8:34 AM: ------------------------------------------------------------------ In rev 5d06826 I've adjusted the AggregateFeaturesMojo to use the new configuration mechanism. The configuration for the mojo now looks like this: {noformat} <configuration> <aggregates> <!-- A list of feature aggregations, each aggregate creates a new feature: --> <aggregate> <classifier/> <!-- optional classifier --> <title/> <!-- optional title--> <description/> <!-- optional description--> <markAsFinal/> <!-- optional flag to mark the feature as final --> <filesInclude/> <!-- optional include for local files, this can be specified more than once --> <filesExclude/> <!-- optional exclude for local files, this can be specified more than once --> <includeArtifact/> <!-- optional artifact for external features, this can be specified more than once --> <includeClassifier/> <!-- optional classifier for local files or aggregates, this can be specified more than once --> </aggregate> </aggregates> </configuration> {noformat} was (Author: cziegeler): In rev 5d06826 I've adjusted the AggregateFeaturesMojo to use the new configuration mechanism. The configuration for the mojo now looks like this: {noformat} <configuration> <aggregates> <!-- A list of feature aggregations, each aggregate creates a new feature: --> <aggregate> <classifier/> <!-- optional classifier --> <title/> <!-- optional title--> <description/> <!-- optional description--> <markAsFinal/> <!-- optional flag to mark the feature as final --> <featureFilesInclude/> <!-- optional include for local files, this can be specified more than once --> <featureFilesExclude/> <!-- optional exclude for local files, this can be specified more than once --> <featureArtifact/> <!-- optional artifact for external features, this can be specified more than once --> <featureClassifier/> <!-- optional classifier for local files or aggregates, this can be specified more than once --> </aggregate> </aggregates> </configuration> {noformat} > Make configuration of slingfeature-maven-plugin consistent > ---------------------------------------------------------- > > Key: SLING-8058 > URL: https://issues.apache.org/jira/browse/SLING-8058 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes > Reporter: Carsten Ziegeler > Priority: Major > Fix For: slingfeature-maven-plugin 1.0.0 > > > The slingfeature-maven-plugin as 2 goals: aggregate-features and repository > that both have slightly different ways of selecting included features. Then > it's also possibly to select via includes at the top level configuration of > the feature. > The top-level includes specifies the initial set of feature files used, the > other goals can then refine this subset. > We should make these consistent. > They should have the same way to: > 1. include/exclude feature files from the total set > 2. refer to a feature file in a maven repository > 3. refer to an aggregated feature done in the same pom, e.g. by just > referring to its classifier, e.g. <aggregateClassifier> > The code that handles this should probably be shared in the ProjectHelper and > it might make sense to create a new shared parent base class, e.g. > AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields > or something like this. > The way it works is: > * The plugin is configured with a directory (features parameter), includes > and excludes for that directory (featuresIncludes, featuresExcludes > parameters) - all of these are defined in the AbstractFeatureMojo > * There is a similar set for testing features in the AbstractFeatureMojo > * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor > which uses all of the above information to create the set of available > features for this project, let's call it the global set of features > * The global set of features is the set of features every mojo should use. > The mojo gets them through the ProjectHelper > * The above mechanism should stay as is and as the Preprocessor is the only > one reading the above mentioned parameters, they are private and not to be > used by any mojo directly > * The aggregate and the repository mojo (and potentially more mojos in the > future) use the above created global set of features and *further* filter it > using includes and excludes. These are additional includes/excludes that only > work on this global set, therefore they should not be part of the > AbstractFeatureMojo > * All these mojos (aggregate and repository) should use the same > configuration and work similar with selecting features > * It makes sense to create a new abstract class to unify this selection, this > abstract class would inherit from AbstractFeatureMojo, add the additional > includes/excludes handling and be used by the mojos like the aggregate and > the repository mojo > I suggest we use the following general configuration format. > For includes, excludes of files from the current projects > {noformat} > <featureFiles> > <include>base.json</include> > <include>something/*.json</include> > <exclude>something/badfile.json</exclude> > </featureFiles> > {noformat} > For features from external projects > {noformat} > <featureArtifact> > </groupId></artifactId>etc. > </featureArtifact> > {noformat} > For aggregates from the same project > {noformat} > <aggregateFeature>CLASSIFIER_NAME</aggregateFeature> > {noformat} > The configuration for the aggregate mojo is then: > {noformat} > <aggregate> > <featureFiles/>* > <featureArtifact>* > <aggregateFeature>* > </aggregate> > {noformat} > The configuration for the repository mojo becomes similarly: > {noformat} > <repository> > <featureFiles/>* > <featureArtifact>* > <aggregateFeature>* > <artifact>* > </repository> > {noformat} > Note that the repository mojo gets an additional configuration for artifacts > to be added to the repository, these are not features -- This message was sent by Atlassian JIRA (v7.6.3#76005)