[
https://issues.apache.org/jira/browse/SLING-13197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080571#comment-18080571
]
Roy Teeuwen commented on SLING-13197:
-------------------------------------
[~cziegeler] exactly.
The goal is to be able to easily make an `it.tests` module that makes a feature
file of my `all` package (containing asm / groovy) and then combine this file
with the sling starter feature model using the `feature-launcher-maven-plugin`
(of which I will also make a PR for to allow it to use multiple feature files
that will be aggregated into one) to create the aggregated module that will
then be launched during the integration tests:
{code:xml}
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>sling-feature-converter-maven-plugin</artifactId>
<!-- Locally-built upgrade of plugin 1.0.12 to use cpconverter 1.3.10 -->
<version>1.0.13-SNAPSHOT</version>
<executions>
<execution>
<id>convert-cp-to-fm</id>
<phase>initialize</phase>
<goals>
<goal>convert-cp</goal>
</goals>
<configuration>
<contentPackages>
<contentPackage>
<groupId>${project.groupId}</groupId>
<artifactId>aem-groovy-console-all</artifactId>
</contentPackage>
</contentPackages>
<fmOutput>${project.build.directory}/cp-conversion/fm.out</fmOutput>
<bundleStartOrder>20</bundleStartOrder>
<installConvertedCP>true</installConvertedCP>
<mergeConfigurations>true</mergeConfigurations>
</configuration>
</execution>
</executions>
</plugin>
{code}
But so fixing the cp converter is the first step before I can fix the
`sling-feature-converter-maven-plugin` and the `feature-launcher-maven-plugin`
> Feature Model: detect Bundle-SymbolicName collisions during assembly
> --------------------------------------------------------------------------
>
> Key: SLING-13197
> URL: https://issues.apache.org/jira/browse/SLING-13197
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
> Affects Versions: Feature Model 2.0.4
> Reporter: Roy Teeuwen
> Assignee: Roy Teeuwen
> Priority: Major
>
> *Context*
> FeatureBuilder.assemble() deduplicates conflicting bundles by Maven
> groupId:artifactId via BuilderContext.addArtifactsOverride(). This is fine
> when the feature file is created through declarations in a pom.xml / maven.
> It stops working when cpconverter is used on a content package and the
> included bundle was not produced by maven and thus doesn't contain an
> embedded META-INF/ pom properties. The cpconverter then falls back to
> deriving coordinates from the OSGi Bundle-SymbolicName.
> Concrete examples I'm hitting this are for example in the aem-groovy-console
> where i'm trying to set up integration tests for it, using the sling starter
> 14 feature model and adding the groovy console as extra feature file by first
> converting it to a feature file:
>
> - Sling Starter 14 feature model ships org.ow2.asm:asm-tree:9.9.1. The same
> jar embedded into a content package and run through cpconverter becomes
> org.objectweb.asm:tree:9.9.1. Different Maven GAVs, identical OSGi
> BSN+Bundle-Version. assemble() lets both through, then Felix at install time
> refuses with Bundle symbolic name and version are not unique:
> org.objectweb.asm.tree:9.9.1.
> - Sling Starter 14 feature model ships org.apache.groovy:groovy-xml:4.0.10.
> The same family of artifacts embedded at version 5.0.5 and run through
> cpconverter becomes groovy-xml:groovy-xml:5.0.5
>
> *Proposed change*
>
> A new opt-in toggle on BuilderContext that enables BSN-collision detection
> during assemble().
> Behaviour when setOsgiBsnCollisionDetection(true) has been called (no-op
> otherwise — full backward compatibility):
> After FeatureBuilder.assemble() finishes the existing GAV-merge, a new pass
> groups the assembled bundles by Bundle-SymbolicName (read from each JAR's
> manifest). For any group of size ≥ 2 the wildcard {*}:{*}:<rule> entries in
> BuilderContext.getArtifactOverrides() are consulted:
> - HIGHEST → keep the bundle with the highest Bundle-Version
> - LATEST → keep the last bundle in iteration order
> - FIRST → keep the first
> - ALL → keep all (effectively disable for this group)
> - A literal version → keep the bundle whose Bundle-Version matches it
> *Backward compatibility*
> Currently I'm going for default osgiBsnCollisionDetection is false →
> BSN-comparison is skipped → existing assemblies behave identically.
> An alternative would be implicit opt-in: detection runs whenever any wildcard
> {*}:{*}:<rule> override is configured, with no separate toggle.
> - Pro: zero new API surface; the change is invisible to anyone not using
> wildcard overrides.
> - Con: a user who adds {*}:{*}:HIGHEST for normal Maven-GAV clashes would
> get BSN-collision detection as an unrelated side effect they may not have
> asked for.
> Will currently go for opt-in, unless everyone is happy with making this the
> default
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
