cowwoc opened a new pull request, #389:
URL: https://github.com/apache/maven-build-cache-extension/pull/389
## Problem
Without executionControl configuration, the build cache does not track
critical plugin properties that are often specified via command-line arguments
(e.g., `-Dmaven.compiler.release`). This leads to incorrect cache reuse when
these properties change between builds.
In multi-module JPMS projects, this manifests as compilation failures or
bytecode version mismatches:
1. Build with `-Dmaven.compiler.release=17` → cache stores Java 17 bytecode
(major version 61)
2. Build with `-Dmaven.compiler.release=21` → cache incorrectly reuses Java
17 bytecode
3. Result: Bytecode remains major version 61 instead of expected 65
This is particularly problematic for `module-info.class` files which are
sensitive to Java version.
## Solution
Implemented default reconciliation configs for common plugins when
executionControl is not specified:
- **maven-compiler-plugin** (`compile` & `testCompile` goals):
- Tracks `source`, `target`, and `release` properties
- Ensures cache invalidation when Java version changes
- **maven-install-plugin** (`install` goal):
- Tracked to ensure local repository is updated when needed
Users can still provide explicit `executionControl` configuration which will
override these defaults.
## Testing
Verified with multi-module JPMS test project. See commit message for
detailed test results.
**Before (broken):**
```bash
mvn clean verify -Dmaven.compiler.release=17 # Caches Java 17 bytecode
mvn clean verify -Dmaven.compiler.release=21 # Incorrectly reuses Java 17
bytecode
javap -v module-info.class | grep "major version" # Shows 61 (wrong!)
```
**After (fixed):**
```bash
mvn clean verify -Dmaven.compiler.release=17 # Caches Java 17 bytecode
mvn clean verify -Dmaven.compiler.release=21 # Detects change, recompiles
javap -v module-info.class | grep "major version" # Shows 65 (correct!)
```
## Impact
- ✅ Users no longer need to manually configure executionControl for basic
scenarios
- ✅ Prevents silent bytecode version mismatches in JPMS projects
- ✅ Backward compatible: explicit executionControl config still takes
precedence
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
