apache / apache/maven-build-cache-extension
[MBUILDCACHE-59] Accommodate Maven CI-friendly versions
- Dominant language
- Java
- Stars
- 163
- Forks
- 77
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 4
Description
**[Bas van Erp](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=JIRAUSER300062)** opened **[MBUILDCACHE-59](https://issues.apache.org/jira/browse/MBUILDCACHE-59?redirect=false)** and commented
I would argue that the Maven Build Cache Extension (MBCE) can provide the greatest value for users that utilize large multi-module (mono-)repositories, since those projects tend to have large amounts of "stable" code which isn't modified frequently.
Speeding up the build of these multi-module projects using the MBCE would be totally awesome!
But for my particular project (200K LOC, 400 modules, mono-repo) our initial trials with the MBCE have proven somewhat troublesome.
It has to do with our use of https://maven.apache.org/maven-ci-friendly.html
## Example setup
`repo/.mvn/maven.config`
```java
-Drevision=0.0.0-local-SNAPSHOT
```
`repo/pom.xml`
```java
com.corp
parent
${revision}
pom
```
`repo/moduleX/pom.xml`
```java
com.corp
parent
${revision}
../pom.xml
moduleX
jar
```
`repo/moduleY/pom.xml`
```java
com.corp
parent
${revision}
../pom.xml
moduleY
jar
com.corp
moduleX
${revision}
```
`repo/Jenkinsfile`
```java
mvn clean deploy -Drevision=$(git describe)
```
## Effect
This setup effectively means that while all our 150 developers might theoretically get decent cache hit % since they are all always using version `0.0.0-local-SNAPSHOT` for every single POM for every single build, our CI pipelines are out of luck.
Since the effective-POMs will change radically with each new Git commit, the hashes will virtually never collide.
## Solution?
I'm very new to the MBCE so I might be way off the mark, but I think accommodating this setup will not be trivial to implement. It would probably require parsing the effective-POM for every module picked-up by the reactor and then removing all \ clauses of the module, the parent, and each dependency and plugin which are part of the reactor build.
Doesn't sound easy to me. But perhaps I'm missing something.
p.s. Congrats on the v1.0.0 release :). I'm enjoying experimenting with it. But the documentation could use some love. It's pretty hard to read. Some paragraphs are confusing, terse or lacking in detail, are clearly written by non-English-native writers (like myself), or even stop mid-sentence.
---
**Affects:** 1.0.0
1 votes, 4 watchers
Contributor guide
No contributing guide indexed for this repository
Research direction
The example uses .mvn/maven.config, the root and module pom.xml files, and Jenkinsfile; start by tracing how the extension derives cache keys from reactor projects and effective-POM versions. Reproduce the CI-friendly ${revision} setup, then define done as cache reuse across commits where reactor artifacts are unchanged without incorrect hits.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100