sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <>
Subject [jira] [Commented] (SLING-8058) Make configuration of slingfeature-maven-plugin consistent
Date Tue, 06 Nov 2018 08:46:01 GMT


Carsten Ziegeler commented on SLING-8058:

Due to the way the maven mojo mapping works, the actual syntax for the configuration is slightly
different than above. This is the current implementation of the FeatureSelectionConfig:
    <!-- The configuration can have a list of featureFilesInclude and featureFilesExclude:

      If at least one of them is specified, local feature files are tried to be included
  <!-- The configuration can have a list of featureArtifact specifying external features:
<!-- The configuration can have a list of featureClassifier, selecting local feature files
based on classifiers.
    This classifier can either point to a feature file as part of the project or to an aggregated
feature file of the project.
    If the asteriks is used as a classifier, all local features files are included, if an
empty classifier is specified, the feature
    without a classifier (main project artifact) is used -->

The various mojos can use this approach by creating a configuration subclass of FeatureSelectionConfig
(an example is the AggregateConfig class) and the mojo should extend AbstractIncludingFeatureMojo
 and call getSelectedFeatures(config) with the config object to get all selected features.

Please note that AggregateConfig should be named Aggregate but that would clash with the current
mojos. As soon as the mojos are changed to use this new approach the renaming can be done.
(Maven looks for a class in the same project based on the property name)

> Make configuration of slingfeature-maven-plugin consistent
> ----------------------------------------------------------
>                 Key: SLING-8058
>                 URL:
>             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

View raw message