FELIX-6759 Follow-up: Make the remaining module builds work on modern JDKs - #555
Open
paulrutter wants to merge 8 commits into
Open
FELIX-6759 Follow-up: Make the remaining module builds work on modern JDKs#555paulrutter wants to merge 8 commits into
paulrutter wants to merge 8 commits into
Conversation
Several modules cannot be built on a current JDK. They declare a felix-parent
version that does not match the local pom, so the relativePath is ignored and Maven
silently resolves an old released felix-parent from Maven Central instead. Those
parents hardcode felix.java.version 6 or 7, and javac rejects release levels below 8
from JDK 20 onwards:
error: release version 7 not supported
They also pin maven-surefire-plugin 2.x, which cannot parse the JDK 25 version string
and fails with a NullPointerException before running any test:
Cannot invoke "...JavaVersion.atLeast(...)" because
"...SystemUtils.JAVA_SPECIFICATION_VERSION_AS_ENUM" is null
Bumping each module to felix-parent 9 fixes both at once, rather than overriding the
compiler and plugin configuration module by module:
bundlerepository felix-parent 2.1 -> 9
connect, log.extension, resolver, utils felix-parent 5 -> 9
Alongside that:
- source/target levels below 8 are raised to 8 in connect, bundlerepository and the
three examples/extenderbased modules, since javac no longer accepts them.
- bundlerepository declares junit and mockito explicitly. felix-parent 2.1 supplied
them to every module and felix-parent 9 does not. mockito-all 1.x is replaced by
mockito-core, because the cglib it bundles cannot generate classes for recent class
file versions.
- resolver moves from mockito-all 1.10.19 to mockito-core for the same reason.
No production code is changed in any of these modules, so no versions are bumped;
recording the resulting execution environment change is left to whoever prepares the
next release of each.
The modules are added to the CI matrix so the builds are actually exercised.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
paulrutter
changed the base branch from
master
to
feature/FELIX-6759-Java-25-LTS
August 29, 2026 21:21
…modern-jdk # Conflicts: # .github/workflows/maven-ci.yml
paulrutter
changed the title
configadmin has the same defect as the other modules here: it declares felix-parent 6
with relativePath ../pom/pom.xml, which does not match the local pom, so Maven
resolves the released felix-parent 6 from Central instead. That parent hardcodes
felix.java.version 7, and javac rejects it:
error: release version 7 not supported
Moving it to felix-parent 9 fixes the build. No production code is changed here, so
no version is bumped.
configadmin was also absent from the workflow's path filters, so a pull request
touching only configadmin matched no trigger and got no build at all. It now has a
filter and a build step.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With configadmin building and running in CI, its integration tests reported 34 errors
in ConfigAdminSecurityTest on JDK 21, 23 and 25, all of them:
java.lang.UnsupportedOperationException: The Security Manager is deprecated
and will be removed in a future release
at java.lang.System.setSecurityManager(System.java:431)
at org.apache.felix.framework.Felix.init(Felix.java:674)
The test launches a framework with org.osgi.framework.security set, so Felix.init
tries to install a Security Manager. System.setSecurityManager has thrown since Java
18 unless -Djava.security.manager=allow is passed, and passing that flag is itself a
fatal startup error from Java 24 on (JEP 486). There is no JDK in the matrix above 17
where this test can pass, and the stack shows it is the released framework 7.0.5 that
configadmin tests against, so this is long standing rather than new.
The test class is excluded from the integration test run with that explanation. It
still runs for anyone building on JDK 17.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The paths-filter entry was named log.extension and the step tested
if: steps.changes.outputs.log.extension == 'true'
A dot in a GitHub expression is property access, so that reads the log filter's
output and then looks up an extension property on the resulting string, which is
always null. The condition could never be true, and the step was skipped on every
run, including the runs that changed log.extension/pom.xml.
The filter is renamed to logextension. Its path stays log.extension/**; only the
key, which has to be a plain identifier, changes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…modern-jdk # Conflicts: # .github/workflows/maven-ci.yml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out of #433, where these changes were scope creep: they are about repairing module builds, not about Java 25 support.
Several modules cannot be built on a current JDK at all. Each declares a
felix-parentversion that does not match the localpom/pom.xml, so therelativePathis ignored and Maven silently resolves an old releasedfelix-parentfrom Maven Central instead. Those parents hardcodefelix.java.version6 or 7, and javac rejects release levels below 8 from JDK 20 onward:They also pin
maven-surefire-plugin2.x, which cannot parse the JDK 25 version string and dies before running a single test:Moving each to
felix-parent 9fixes both at once, rather than overriding compiler and plugin configuration module by module.bundlerepositoryconnect,log.extension,resolver,utilsAlongside that:
source/targetlevels below 8 raised to 8 inconnect,bundlerepositoryand the threeexamples/extenderbased.*modules.bundlerepositorydeclares junit and mockito explicitly —felix-parent2.1 supplied them to every module andfelix-parent9 does not.mockito-all1.x is replaced bymockito-core, since its bundled cglib cannot generate classes for recent class file versions.resolvermoves offmockito-allfor the same reason.No production code is changed in any of these modules, so no versions are bumped. Repairing the parent does raise each module's
osgi.ee(1.5/1.6/1.7 → 1.8), but those levels were themselves accidental — a consequence of resolving a stale parent rather than a deliberate choice — and the version of the next release is better decided by whoever prepares it, against everything that lands before then.The modules are added to the CI matrix so these builds are actually exercised rather than assumed.
🤖 Generated with Claude Code