[
https://issues.apache.org/jira/browse/SLING-13233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18085891#comment-18085891
]
Roy Teeuwen commented on SLING-13233:
-------------------------------------
[~rombert]:
Wanted flow that I want to achieve is to be able to create a maven module
(called for example `it.tests`) that:
* Create a feature file based on a sibling / other module
* Aggregate that feature file with an existing feature file (sling starter)
* Launch te result
* Run the tests
How I now implemented it:
# sling-feature-converter-maven-plugin:convert-cp runs at initialize for
converting an `all` package to a feature file and outputs it in
${project.build.directory}/cp-conversion/fm.out/*.json
# feature-launcher-maven-plugin aggregates it and launches the result to be
available for the integration tests in the
I tried to implement it using the slingfeature-maven-plugin but ran into issues:
*Root cause.* in slingfeature-maven-plugin the
DependencyLifecycleParticipant.afterProjectsRead runs new
Preprocessor().process(env) once per reactor, before any Maven phase fires.
Preprocessor.readProjectFeatures scans ${project.basedir}/${features-dir} at
that moment. Nothing written to target/ later in the build is visible to the
aggregator — only the participant tells it which files exist.
What I could do to slingfeature-maven-plugin instead of this change: add an
<additionalFeatureFiles> — list of paths, resolved at goal time (not at session
start). Read inside AggregateFeaturesMojo after the existing
Preprocessor-derived selections are processed. Lets generated files contribute
to the aggregate without breaking the participant's session-start
*Benefits*
* Restores aggregate-features as the single source of truth for assembly when
the input set contains both Maven-coordinate features (Sling Starter etc.) and
dynamically-generated files (cp-converter output, scripted feature.json, etc.).
Today the launcher plugin has to duplicate this responsibility.
* Aggregated feature is attached to the project — cacheable across mvn verify
invocations; the launcher just consumes the attached artifact.
* No behavioural change for existing consumers: both new parameters default to
"off"/empty.
* Lifecycle participant is untouched, so the transitive-dep declaration path
is unaffected.
*Drawbacks / caveats*
- Asymmetric file discovery. Two paths into the aggregator now: the
session-start Preprocessor scan, plus a goal-time read of
<additionalFeatureFiles>.
- Files in <additionalFeatureFiles> are NOT registered as Maven dependencies
of the project — the participant is what does that, and it's run before they
exist. For pure-output-of-this-build files that's fine (they're not Maven
artifacts). For cases where the file later needs to be referenced from another
module's <includeArtifact>, users should attach-artifact it separately.
- Doesn't solve every dynamic-feature scenario. A multi-module reactor where
module A produces a feature and module B consumes it via <includeArtifact>
(Maven coordinates) still doesn't work in one invocation, because the
participant in module B still runs before A's install.
{*}Alternative (rejected){*}: defer the Preprocessor scan to goal time
The participant currently registers feature artifacts as Maven dependencies
during afterProjectsRead so they enter Maven's dep graph and downstream
resolution works. Moving that to goal time is risks breaking the "feature
artifacts are first-class Maven dependencies" property other consumers might
rely on.
I have a pr open in slingfeature-maven-plugin, go ahead and see if this would
be better as a result:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/100
> Multi-feature aggregation: add <featureFiles>, <features>,
> <osgiBsnCollisionDetection>, <artifactClashOverrides>
> -----------------------------------------------------------------------------------------------------------------
>
> Key: SLING-13233
> URL: https://issues.apache.org/jira/browse/SLING-13233
> Project: Sling
> Issue Type: New Feature
> Affects Versions: Feature Launcher Maven Plugin 1.0.4
> Reporter: Roy Teeuwen
> Assignee: Roy Teeuwen
> Priority: Major
> Fix For: Feature Launcher Maven Plugin 1.0.6
>
>
> The <launch> element currently accepts exactly one of <feature> (Maven
> coordinates) or <featureFile> (local path), validated as mutually exclusive.
> This forces users who want to aggregate (e.g. Sling Starter + a downstream
> feature, or a base feature + tweaks) to either:
> * Pre-merge externally with a script that calls FeatureBuilder.assemble
> themselves, then point <featureFile> at the result, or
> * Skip the plugin entirely and shell out to the launcher tar.gz with their
> own arg construction.
> Both lose the plugin's start/stop lifecycle, attached-artifacts dir,
> port/repo plumbing, and JAVA_HOME fallback.
> This feature is meant to add all the capabilities that the CLI already
> supports (add <featureFiles>, <features>, <osgiBsnCollisionDetection>,
> <artifactClashOverrides>)
> Backward compatibility: The only meaningful semantic change: combining
> <feature> and <featureFile> was previously rejected at validation; now it's
> accepted as a two-feature aggregation. Existing single-feature configurations
> continue to work unchanged. The new fields are all optional with empty-list /
> false defaults.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
