You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Roy Teeuwen (Jira)" <ji...@apache.org> on 2026/05/08 19:44:00 UTC
[jira] [Assigned] (SLING-13197) Feature Model: detect Bundle-SymbolicName collisions during assembly
[ https://issues.apache.org/jira/browse/SLING-13197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roy Teeuwen reassigned SLING-13197:
-----------------------------------
Assignee: Roy Teeuwen
> 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)