royteeuwen opened a new pull request, #100:
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/100

   ## Summary
   
   Adds two parameters to `<aggregate>` in 
`slingfeature-maven-plugin:aggregate-features` to support the same aggregation 
use case covered by the open launcher-plugin PR 
https://github.com/apache/sling-feature-launcher-maven-plugin/pull/32 — but at 
the slingfeature-maven-plugin layer:
   
   * **`<additionalFeatureFiles>`** — a list of feature JSON files read at goal 
time and merged into the aggregation selection. Unlike `<filesInclude>`, these 
bypass the session-start `Preprocessor` scan and may therefore live under 
`target/` (i.e. be produced earlier in the same build by another plugin, e.g. 
`sling-feature-converter-maven-plugin:convert-cp`).
   * **`<osgiBsnCollisionDetection>`** — when `true`, plumbs 
`BuilderContext.setOsgiBsnCollisionDetection(true)` through (requires 
`org.apache.sling.feature` ≥ 2.0.6, 
[SLING-13197](https://issues.apache.org/jira/browse/SLING-13197)). When two 
bundles share the same `Bundle-SymbolicName` + `Bundle-Version` across 
different Maven coordinates, the build fails unless an existing 
`<artifactsOverrides>` wildcard rule (e.g. `*:*:HIGHEST`) resolves the 
collision.
   
   `org.apache.sling.feature` is bumped 2.0.0 → 2.0.6 for the new 
BuilderContext API.
   
   ## Alternative to PR #32 in feature-launcher-maven-plugin
   
   
[apache/sling-feature-launcher-maven-plugin#32](https://github.com/apache/sling-feature-launcher-maven-plugin/pull/32)
 adds equivalent `<featureFiles>` + `<osgiBsnCollisionDetection>` parameters to 
`feature-launcher-maven-plugin`, performing the aggregation inside the launcher 
at JVM start. Both approaches produce the same effective feature graph; the 
trade-off is:
   
   | | This PR | PR #32 |
   |---|---|---|
   | Aggregation timing | `generate-resources` (Maven build) | launcher 
bootstrap (JVM start) |
   | Aggregated JSON visible to other goals in the same build | yes (e.g. 
`analyse-features`, `embed-features`, `repository`) | no — launcher-internal 
only |
   | Requires `<extensions>true</extensions>` | yes | no |
   
   Submitting both so the Sling maintainers can pick whichever layer fits best 
— happy to drop one if a clear preference emerges, or land both since they do 
not conflict.
   
   ## Validation
   
   Validated end-to-end against 
[orbinson/aem-groovy-console](https://github.com/orbinson/aem-groovy-console) 
integration tests with a three-plugin pipeline:
   
   | Phase | Plugin |
   |---|---|
   | `initialize` | `sling-feature-converter-maven-plugin:1.0.14` — 
`convert-cp` |
   | `generate-resources` | `slingfeature-maven-plugin` (this PR) — 
`aggregate-features` with `<additionalFeatureFiles>` + 
`<osgiBsnCollisionDetection>` |
   | `pre-integration-test` | `feature-launcher-maven-plugin:1.0.4` — `start` 
with `<featureFile>` pointing at the aggregator output |
   
   Result: 14/14 ITs pass.
   
   ## Test plan
   
   - [x] 3 new unit tests in `AggregateFeaturesMojoTest`: additional file 
merged, missing file throws `MojoExecutionException`, BSN-collision flag 
propagates without crashing on a non-colliding aggregate
   - [x] 20/20 existing unit tests in `AggregateFeaturesMojoTest` still pass
   - [x] 16/16 plugin integration tests still pass
   - [x] Spotless / enforcer clean
   - [x] End-to-end aem-groovy-console IT suite green (14/14) with this plugin 
as part of the three-plugin pipeline above
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to