[SITES-44663] core.wcm.components.core bundle is not installable on AEM 6.5 / 6.5 LTS — commons-lang3 OSGi import range too narrow

[LSantha]

Q	A
Fixed Issues?	SITES-44663
Patch: Bug Fix?	Yes
Minor: New Feature?
Major: Breaking Change?
Tests Added + Pass?	No new tests; existing tests pass. Verification happens via the 6.5 / 6.5 LTS CI executions.
Documentation Provided	N/A
Any Dependency Changes?	No — compile-time commons-lang3 stays at 3.20.0 in parent/pom.xml.
License	Apache License, Version 2.0

Problem

Since commit bd91365a (PR #3015, 2026-05-05) bumped commons-lang3 to 3.20.0 in parent/pom.xml, the OSGi Import-Package range generated for com.adobe.cq.core.wcm.components.core became [3.20.0, 4.0.0). No publicly released AEM 6.5 GA or 6.5 LTS Service Pack ships commons-lang3 in that range, so the core bundle fails to resolve on every released AEM 6.5 / LTS instance:

*ERROR* Events.Framework.com.adobe.cq.core.wcm.components.core
FrameworkEvent ERROR (org.osgi.framework.BundleException:
  Unable to resolve com.adobe.cq.core.wcm.components.core [...]:
  missing requirement osgi.wiring.package;
  (&(osgi.wiring.package=org.apache.commons.lang3)
   (version>=3.20.0)(!(version>=4.0.0)))

commons-lang3 shipped by each released AEM 6.5 / LTS SP

(Sourced from the official Adobe docs bundle lists.)

AEM version	Released	commons-lang3	Meets >=3.20?
AEM 6.5.18 (CI baseline)	observed at runtime	3.12.0	❌
AEM 6.5.19	—	3.13.0	❌
AEM 6.5.21 / 6.5.23	—	3.14.0	❌
AEM 6.5.24 — latest 6.5 GA	Nov 2025	3.18.0	❌
AEM 6.5 LTS SP1	Mar 2025	3.17.0	❌
AEM 6.5 LTS SP2 — latest LTS	Feb 2026	3.19.0	❌

What the bundle actually uses

Only 6 commons-lang3 classes are referenced across all 90 files in bundles/core/src/main/java/:

• org.apache.commons.lang3.StringUtils
• org.apache.commons.lang3.ArrayUtils
• org.apache.commons.lang3.ObjectUtils
• org.apache.commons.lang3.CharEncoding
• org.apache.commons.lang3.tuple.Pair
• org.apache.commons.lang3.tuple.ImmutablePair

All of these are available since commons-lang3 3.0/3.1, so the auto-generated [3.20.0, 4.0.0) range is unnecessarily strict.

Fix

Add explicit Import-Package directives so the bundle resolves on commons-lang3 ≥ 3.12 at runtime, while the compile-time dependency stays at 3.20.0:

-                            com.adobe.cq.dam.cfm.converter;version="[1,2)",
+                            com.adobe.cq.dam.cfm.converter;version="[1,2)",
+                            org.apache.commons.lang3;version="[3.12,4)",
+                            org.apache.commons.lang3.tuple;version="[3.12,4)",
                             *
                         </Import-Package>

Verification

Local build of bundles/core now produces a manifest with the widened range:

Import-Package: ...,
  org.apache.commons.lang3;version="[3.12,4)",
  org.apache.commons.lang3.tuple;version="[3.12,4)",
  ...

Final verification will come from the CI matrix executions (github-aem-core-wcm-components-main, CQ_VERSION=6.5.0 and CQ_VERSION=6.5.LTS) once this PR is merged — both have been UNSTABLE or FAILURE for weeks because of this issue.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[stefanseifert]

@LSantha wouldn't it had been safer to decrease the version number in parent pom for commons-lang3 to 3.12 - then you don't have to override the OSGi import-package statement? alternatively, decrease to 3.19 which is at least available in latest SP for 6.5 and 6.6/6.5 LTS.

with this change, you risk that new code makes use of commons-lang3 features not available in version 3.12 - but you will only realize it when the java code fails at runtime, as you have canceled out the OSGi version checking mechanisms which would have failed the build early otherwise.