[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677993#comment-16677993
]
Carsten Ziegeler commented on SLING-8058:
-----------------------------------------
I've updated the analysis mojo in rev 870f428. The analysis mojo without any
additonal configuration works as before. But you can also specify a list of
scans:
{noformat}
<configuration>
<scans>
<!-- A list of scans, each creates a new analysis: -->
<scan>
<includeTask/> <!-- optional include for analysis tasks, this
can be specified more than once-->
<excludeTask/> <!-- optional exclude for analysis tasks, this can
be specified more than once -->
<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 -->
</scan>
</scans>
</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)
