Recompile when dependencies change by wilx · Pull Request #1102 · apache/maven-compiler-plugin

wilx · 2026-07-31T21:46:21Z

Summary

persist the ordered class path and module path in the plugin-local dependencies.lst state file
collect persisted metadata and the current-build timestamp fallback in one cached scan per normalized dependency path, removing the previous duplicate traversal
record regular dependency files as size and modification time, and exploded dependency directories as a stable metadata fingerprint
trigger the existing changed dependency rebuild reason when dependencies are added, removed, reordered, relocated, or replaced at the same path
add unit coverage for the consolidated detector and integration coverage for dependency removal and same-path SNAPSHOT replacement

Why

The 3.x incremental check only considered dependency timestamps relative to the current Maven session. It could therefore miss a dependency removed between invocations or a JAR replaced at the same path before the next invocation, leaving stale application bytecode.

The persisted comparison and the existing session-relative fallback are now consolidated. A missing baseline still detects dependencies rebuilt during the current Maven invocation, while unchanged builds no longer walk exploded dependencies once for persisted state and again for the timestamp fallback.

Validation

JAVA_HOME=/opt/jdks/latest-8 /opt/maven/latest/bin/mvn clean verify — 36 tests passed
JAVA_HOME=/opt/jdks/latest-21 /opt/maven/latest/bin/mvn clean verify — 36 tests passed
focused MCOMPILER-349, MCOMPILER-474, dependency-removal, and same-path-replacement integration tests passed
JAVA_HOME=/opt/jdks/latest-21 /opt/maven/latest/bin/mvn -Prun-its clean verify — 78 builds passed, 5 environment-specific skips

Fixes #1087

Following this checklist to help us incorporate your
contribution quickly and easily:

An issue is filed for this change: No recompilation if the dependencies have changed #1087. This pull request addresses only that issue.
Each commit in the pull request has a meaningful subject line and body.
The pull request title describes the issue. The template's [MCOMPILER-XXX] convention is not applicable because this is tracked as GitHub issue No recompilation if the dependencies have changed #1087.
The pull request description explains what the pull request does, how, and why.
Ran mvn clean verify.
Ran the integration tests successfully with mvn -Prun-its clean verify.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.

Persist ordered classpath and module-path dependency state between plugin invocations. Compare file metadata and stable directory fingerprints while preserving current-build timestamp detection in the same scan, so removed, reordered, relocated, and same-path replaced dependencies trigger recompilation without duplicate directory traversal. Fixes apache#1087

elharo · 2026-08-07T11:13:18Z

+        }
+        if (changedDependency != null) {
+            if (configuration.log.isDebugEnabled() || configuration.showChanges) {
+                configuration.log.info("\tNew dependency detected: " + changedDependency.toAbsolutePath());


I wouldn't log this above debug level

The log.info is there because it is possible to get the line printed with user supplied maven.compiler.showCompilationChanges property. If it were log.debug it would not print if the user asked via the property. I can change it to debug for configuration.log.isDebugEnabled() and keep the info for configuration.showChanges. But that seems unnecessarily nuanced.

elharo · 2026-08-07T11:14:18Z

+            }
+        }
+
+        List<Path> files;


This belongs inside the try, as does all the code that depends on it. Don't split variable declaration and initialization

elharo · 2026-08-07T11:15:38Z

+                    changedDependency = file;
+                }
+            } catch (IOException e) {
+                if (!unreadable) {


should you just break out of the loop in this case?

Fixed by merging the two try/catch regions.

elharo · 2026-08-07T11:17:02Z

+    }
+
+    private static String fileMetadata(BasicFileAttributes attributes) {
+        return attributes.size() + ":" + attributes.lastModifiedTime().toMillis();


Seems wonky to be using a string where this method is called instead of the raw attributes.

It fits into how it is stored and used. This way the checksum of files in a dir is only computed via checksum of their metadata checksums/strings, there is only one update function. Doing anything else would complicate things unnecessarily.

elharo · 2026-08-07T11:18:17Z

+        digest.update((byte) 0);
+    }
+
+    private static String toHexString(byte[] bytes) {


This method isn't very risky, but I wouldn't be surprised if there's a utility method to do this somewhere in the classpath already, and if so we should use it. I think there's one in the JDK circa Java 17 but we might not depend on that version yet.

I can't see any function that would be widely available.

elharo · 2026-08-07T11:19:23Z

+
+    private static MessageDigest newDigest() {
+        try {
+            return MessageDigest.getInstance("SHA-256");


unusual choice. Most of the time it would be SHA-1 for speed or SHA-512 for security. I'm not sure securtiy matters here. Does it?

Why unusual? It seems to be used a lot everywhere. It is AFAIK what Git has chosen as successor of SHA-1. It is a middle ground between the speed and security.

elharo · 2026-08-07T11:19:54Z

+            log.info("\tDependency path (+): " + dependencyAdded);
+        }
+        for (String dependencyRemoved : pathChanges.getRemoved()) {
+            log.info("\tDependency path (-): " + dependencyRemoved);


feels like this should all be debug level

It is already gated by maven.compiler.showCompilationChanges property.

elharo · 2026-08-07T11:20:47Z

+
+        if (hasPreviousState && !oldState.equals(newState)) {
+            if (configuration.log.isDebugEnabled() || configuration.showChanges) {
+                logChanges(oldState, newState, configuration.log);


checking debug here is good, but it's info level in the logChanges method. logChanges should log at debug level

It is already gated by maven.compiler.showCompilationChanges property.

…gle try/catch.

wilx marked this pull request as ready for review July 31, 2026 21:48

wilx marked this pull request as draft July 31, 2026 22:19

wilx force-pushed the issue-1087-dependency-state branch from 3d01630 to 665f6cf Compare July 31, 2026 22:42

wilx marked this pull request as ready for review July 31, 2026 22:43

wilx force-pushed the issue-1087-dependency-state branch from 665f6cf to 096cfb4 Compare July 31, 2026 23:25

elharo requested changes Aug 7, 2026

View reviewed changes

elharo requested a review from gnodet August 7, 2026 11:21

DependencyState: Merge directory walk and digest computation into sin…

f260b89

…gle try/catch.

Uh oh!

Conversation

wilx commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Validation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilx Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

wilx commented Jul 31, 2026 •

edited

Loading

wilx Aug 7, 2026 •

edited

Loading