You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "olamy (via GitHub)" <gi...@apache.org> on 2026/09/03 08:23:13 UTC
[I] Plugin config directory probing hashes other modules' target/ output as inputs, permanently invalidating the cache [maven-build-cache-extension]
olamy opened a new issue, #525:
URL: https://github.com/apache/maven-build-cache-extension/issues/525
### Summary
When the input scanner probes plugin configuration for paths, a `<directory>` (or any path-valued tag) that points at **another module's directory** is walked recursively, and that module's `target/` is **not** excluded. The other module's build output — jar, `target/classes/*.class`, `maven-archiver/pom.properties`, `maven-status/**` — therefore becomes part of the consuming module's checksum.
Build output is not stable across builds (jars carry timestamps unless `project.build.outputTimestamp` is set, and `maven-status` files change whenever the module is actually compiled rather than restored). The result is a module that can never get a cache hit, with no warning — it just looks like the remote cache is broken.
`ExclusionResolver.addDefaultExcludes()` builds the `target` / `target/classes` / `target/test-classes` exclusions from **the current project only**:
```java
Path buildDirectoryPath = absoluteNormalizedPath(build.getDirectory());
Path outputDirectoryPath = absoluteNormalizedPath(build.getOutputDirectory());
Path testOutputDirectoryPath = absoluteNormalizedPath(build.getTestOutputDirectory());
```
They are absolute paths, so they only ever match the project being hashed. Any *other* reactor module reached through plugin-config probing has its build output treated as source input.
### Reproducer
Note: create it **outside** `java.io.tmpdir` — `getPathOrNull()` silently skips anything under the temp dir, so a repro in `/tmp` will not trigger the scan.
```bash
mkdir -p ~/mbc-repro/{.mvn,mod-a/src/main/java,mod-b/src/main/java} && cd ~/mbc-repro
cat > .mvn/extensions.xml <<'EOF'
<extensions>
<extension>
<groupId>org.apache.maven.extensions</groupId>
<artifactId>maven-build-cache-extension</artifactId>
<version>1.3.0</version>
</extension>
</extensions>
EOF
cat > .mvn/maven-build-cache-config.xml <<'EOF'
<cache xmlns="https://maven.apache.org/BUILD-CACHE-CONFIG/1.2.0">
<configuration>
<enabled>true</enabled>
<hashAlgorithm>XX</hashAlgorithm>
</configuration>
<input>
<global>
<glob>{*.java,*.xml,*.properties}</glob>
</global>
</input>
</cache>
EOF
cat > pom.xml <<'EOF'
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>org.example</groupId>
<artifactId>parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<maven.compiler.release>17</maven.compiler.release>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<modules>
<module>mod-a</module>
<module>mod-b</module>
</modules>
</project>
EOF
cat > mod-a/pom.xml <<'EOF'
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.example</groupId>
<artifactId>parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>mod-a</artifactId>
</project>
EOF
echo 'public class A {}' > mod-a/src/main/java/A.java
echo 'shared note' > mod-a/notes.txt
# mod-b has NO dependency on mod-a. It only wants one file out of mod-a's directory.
cat > mod-b/pom.xml <<'EOF'
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.example</groupId>
<artifactId>parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>mod-b</artifactId>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-shared-note</id>
<phase>prepare-package</phase>
<goals><goal>copy-resources</goal></goals>
<configuration>
<outputDirectory>${project.build.directory}</outputDirectory>
<resources>
<resource>
<directory>${maven.multiModuleProjectDirectory}/mod-a</directory>
<includes><include>notes.txt</include></includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
EOF
echo 'public class B {}' > mod-b/src/main/java/B.java
mvn -B -ntp -Dmaven.build.cache.location=$PWD/cache clean install # warm
mvn -B -ntp -Dmaven.build.cache.location=$PWD/cache clean install # mod-b hits
# a CI agent that has to rebuild mod-a. No source change anywhere.
rm -rf cache/v1.2/org.example/mod-a
mvn -B -ntp -Dmaven.build.cache.location=$PWD/cache clean install
```
### Actual
The last build misses on `mod-b`, although nothing in `mod-b` — or in any *source* file — changed:
```
[INFO] Local build was not found by checksum 65e6bd150bbbd545 for org.example:mod-b
```
`mod-b`'s `buildinfo.xml` shows why:
```
file 2eaf0644a54b6fa5 ../mod-a/target/classes/A.class
file d4bdf912ad00f859 ../mod-a/target/maven-archiver/pom.properties
file b12c0741ec50f3fc ../mod-a/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst
file 847b95fc10a3e8b6 ../mod-a/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst
file c918f0a5600bfbf0 ../mod-a/target/mod-a-1.0-SNAPSHOT.jar
file ... ../mod-a/notes.txt, ../mod-a/pom.xml, ../mod-a/src/main/java/A.java
file ... src/main/java/B.java
```
Editing anything in `mod-a` also invalidates `mod-b` the same way, even though `mod-b` does not depend on `mod-a`.
The input set additionally differs depending on whether `mod-a` was **restored** (only the jar is present in `target/`) or **rebuilt** (whole `target/` tree present), so the two paths produce different checksums for the same sources.
### Expected
Another module's build output directory should never be a checksum input. Either exclude every reactor project's `build.directory` when walking, or apply the owning project's default exclusions when the walked path belongs to a different `MavenProject` in the session — `MultiModuleSupport` already has the project list.
### Secondary: the configured `<global><glob>` is bypassed for plugin-config scans
`notes.txt` above is collected even though the configured glob is `{*.java,*.xml,*.properties}`, because `DefaultPluginScanConfig` — used whenever a plugin has no explicit `<dirScan>` — hardcodes `*`:
```java
// DefaultPluginScanConfig
public ScanConfigProperties getTagScanProperties(String tagName) {
return new ScanConfigProperties(true, "*");
}
```
whereas `PluginScanConfigImpl.defaultScanConfig()` returns `null`, which `MavenProjectInput` then resolves to the project glob:
```java
final String glob = defaultIfEmpty(propertyConfig.getGlob(), projectGlob);
```
So adding an otherwise-empty `<dirScan/>` for a plugin silently *narrows* the scanned file set from `*` to the project glob. That asymmetry looks unintentional.
### Real-world impact
Found while investigating why Eclipse Jetty's CI never got a single cache hit. Jetty's parent pom has an inherited `maven-resources-plugin` execution pointing at `${maven.multiModuleProjectDirectory}/build`, which contains a helper module. Every one of the ~400 reactor modules therefore hashed `build/build-resources/target/build-resources-<version>.jar`, which is not reproducible — so the entire reactor invalidated itself on every build, on every agent, forever. Diagnosing it took diffing `buildinfo.xml` between two runs, because nothing in the log hints that an input lives under another module's `target/`.
A warning when a collected input falls under any reactor project's build directory would make this class of problem self-diagnosing.
### Environment
- maven-build-cache-extension 1.3.0
- Maven 3.9.16
- Java 25.0.3 (Temurin); also observed on 17 and 21
--
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: issues-unsubscribe@maven.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org