[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8058:
------------------------------------
Description:
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
was:
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
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
> 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: 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)
