Add default executionControl reconciliation for common Maven plugins

[cowwoc]

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):

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):

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

Related Issues

This PR addresses multiple user-reported issues:

• Support Java Modules and Multi-Module Projects out of the box #373 - Support Java Modules and Multi-Module Projects out of the box (directly addresses the request for default compiler reconciliation)
• Maven Build Cache Extension incorrectly handles --module-version compiler arguments for Java modules, causing cache invalidation on every build despite no source code changes #375 - Maven Build Cache Extension incorrectly handles --module-version compiler arguments (related compiler argument tracking issue)
• [MBUILDCACHE-73] Add project version as additional property for reconcilation #268 - Add project version as additional property for reconciliation (similar tracking requirement)
• [MBUILDCACHE-92] Allow to define 'reconciles' at plugin execution level #272 - Allow to define 'reconciles' at plugin execution level (related reconciliation configuration)

[AlexanderAshitkin]

I approve this change because it does not introduce any regressions and indeed, could fix certain scenarios. However, I would prefer the following enhancements:

1. An integration test that verifies the fix. This should include scenarios such as:

   • No configuration set
   • No plugin configuration set
   • If plugin reconciliation set, the default is overridden (or merged)

2. Although this is definitely a step in the right direction, I would love to see some ground work to make this configuration extensible.

To achieve this, I suggest the following:

1. For each plugin, export its all parameters to xml (per plugin).
2. For the exported parameters, annotate each one as either "behavioral" or "functional." (further categorization might also help). For example, the number of compiler threads or log level would be considered behavioral parameters, whereas the target level would be functional.

The goal is to create a closed and matching set of parameters for default configurations for every plugin, every goal. The current implementation does not enforce the categorization of all parameters, which can lead to incorrect behavior if the plugin is modified (for instance, if a critical parameter is renamed).

Ideally, the default configuration should fail on encountering an unknown parameter or at least emit a warning.

[cowwoc]

To achieve this, I suggest the following:

For each plugin, export its all parameters to xml (per plugin).
For the exported parameters, annotate each one as either "behavioral" or "functional." (further categorization might also help). For example, the number of compiler threads or log level would be considered behavioral parameters, whereas the target level would be functional.
The goal is to create a closed and matching set of parameters for default configurations for every plugin, every goal. The current implementation does not enforce the categorization of all parameters, which can lead to incorrect behavior if the plugin is modified (for instance, if a critical parameter is renamed).

Ideally, the default configuration should fail on encountering an unknown parameter or at least emit a warning.

@AlexanderAshitkin So if I understand you correctly, for the limited number of plugins that we supply defaults for, you want to provide enhanced validation to ensure that we log a warning if a user attempts to track changes of a non-existent or behavioral parameter. Is that correct?

Take a look at the latest commit I pushed and let me know if this matches what you had in mind. Thanks.

[AlexanderAshitkin]

This is a good improvement. Please recategorize skip parameters to functional, and I’d like to get feedback on the possibility of direct reconciliation using the new plugin descriptors.