gradle-baseline
gradle-baseline copied to clipboard
Improve logging and restore correct `--add-exports` handling in `BaselineModuleJvmArgs`
Before this PR
In https://github.com/palantir/gradle-baseline/pull/3119 we fixed configuration cache for baseline but this has introduced and error where exports where not being correctly added and the logging was incorrect:
2025-06-20T09:09:39.332-0400 [DEBUG] [com.palantir.baseline.plugins.BaselineModuleJvmArgs$ModuleJvmArgsArgumentProvider] BaselineModuleJvmArgs executing task on project property 'projectPath' with exports: []
This appears to have been caused by eagerly calling test.getClasspath() which caused the classpath to be resolved at configuration time, before all dependencies (including those added later or via plugins) were present. As a result, any module --add-exports or --add-opens entries contributed by jars added after the initial configuration phase were missed. This led to missing JVM arguments for runtime tasks such as Test and JavaExec.
After this PR
This PR defers evaluation of the classpath by wiring the provider with a Callable/Provider that resolves the classpath at execution time, ensuring that all jars (including those added late) are correctly included. This restores the expected behavior: all relevant --add-exports and --add-opens flags are present for runtime tasks, regardless of when dependencies are added. Logging is fixed to show the actual task and project names rather than property objects
This results in a restored fucntionallity:
2025-06-20T15:01:18.095+0100 [DEBUG] [com.palantir.baseline.plugins.BaselineModuleJvmArgs$ModuleJvmArgsArgumentProvider] BaselineModuleJvmArgs executing <redacted> on project <redacted> with exports: [--add-exports, java.base/jdk.internal.platform=ALL-UNNAMED, --add-exports, java.base/sun.net=ALL-UNNAMED, --add-exports, java.management/sun.management=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED, --add-exports, jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED, --add-exports, jdk.jfr/jdk.jfr.internal=ALL-UNNAMED, --add-opens, java.base/java.lang.invoke=ALL-UNNAMED, --add-opens, java.base/java.net=ALL-UNNAMED]
==COMMIT_MSG==
Fixes incorrect logging and restores correct handling of --add-exports and --add-opens in BaselineModuleJvmArgs
This change defers evaluation of the classpath to execution time, ensuring all relevant jars are included and their manifest entries are respected.
==COMMIT_MSG==
Possible downsides?
Generate changelog in changelog/@unreleased
changelog/@unreleasedType (Select exactly one)
- [ ] Feature (Adding new functionality)
- [ ] Improvement (Improving existing functionality)
- [x] Fix (Fixing an issue with existing functionality)
- [ ] Break (Creating a new major version by breaking public APIs)
- [ ] Deprecation (Removing functionality in a non-breaking way)
- [ ] Migration (Automatically moving data/functionality to a new system)
Description
--add-exports and --add-opens in BaselineModuleJvmArgs
This change defers evaluation of the classpath to execution time, ensuring all relevant jars are included and their manifest entries are respected.
Check the box to generate changelog(s)
- [x] Generate changelog entry
Can we get some sort of test that verifies this fix?
Added a test
Released 6.39.0