ppkarwasz opened a new pull request, #4260: URL: https://github.com/apache/logging-log4j2/pull/4260
The `log4j-api-java9` and `log4j-core-java9` modules are a relict from an era where multi-release JAR content could not be produced by the consuming Maven module itself. Each compiled a handful of Java 9 sources (padded with stub classes to satisfy the compiler, since `log4j-api-java9` had no dependency on `log4j-api`), zipped the compiled classes in a `classes/META-INF/versions/9` layout, and had the consumer unpack the zip into `target` at `prepare-package`. This PR compiles the Java 9 sources directly in `log4j-api` and `log4j-core` instead, using a second `maven-compiler-plugin` execution over a new `src/main/java9` source directory with `<release>9</release>` and `<multiReleaseOutput>true</multiReleaseOutput>`, and deletes the two auxiliary modules (including all their stub classes, which are no longer needed: the real classes from `target/classes` are on the compile classpath). **The published artifacts are unchanged**: the versioned class list and the entry sizes in `log4j-api.jar` and `log4j-core.jar` are identical before and after (same compiler version, flags and JDK), the `Multi-Release: true` manifest entry keeps coming from the `bnd-multi-release` property, and the versioned classes are still compiled at class-file version 53. The new compiler execution stays bound to `prepare-package` so that `bnd-maven-plugin` (running at `process-classes`) never sees the versioned classes — the same timing the zip-unpack mechanism had (cf. apache/logging-parent#93). The existing `delete-module-descriptors` clean execution keeps incremental no-clean builds correct. Other clean-ups that fall out of this: * the dead `build-helper-maven-plugin` `add-source` executions in both consumers (they added a `target/log4j-*-java9` directory that never existed) are removed; * the `dependencyManagement` entries for the zip artifacts in `log4j-parent` are removed (they were never in the published BOM, cf. LOG4J2-3241). **Tests**: the Java 9 `StackLocator` tests move to `log4j-api-test` as a `maven-failsafe-plugin` integration test (`StackLocatorJava9IT`) that runs against the packaged multi-release JAR, with a guard assertion that the `META-INF/versions/9` variant of `StackLocator` is actually loaded. Two remarks: * The two `getCurrentStackTrace` tests are dropped, not moved: they only passed against the old module's stubbed `PrivateSecurityManagerStackTraceUtil` (whose `isEnabled()` returned `false`). Against the real classes on JDK 17 they exercise the `SecurityManager` path, which `StackLocatorUtilTest` already covers. The Java 9 `ProcessIdUtilTest` was assertion-identical to the existing one in `log4j-api-test` and is dropped too. * The failsafe execution is restricted to the new `java9` package, because the pre-existing (and currently never executed) `StackLocatorTestIT` installs a `SecurityManager` and fails on JDK 17 without `-Djava.security.manager=allow`; reviving it is a separate follow-up. **Visible losses**: * the moved sources in `src/main/java9` now fall outside the default `src/main/java` globs of Spotless and RAT, so they lose automatic format/license-header enforcement (9 stable files; an `<includes>` override in `logging-parent` or here is possible as a follow-up); * the Java 9 sources are, as before, absent from the published sources JARs. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01RTbXEN6DStfnmMLSMPWM9b -- 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]
