apache / apache/maven-build-cache-extension

[MBUILDCACHE-59] Accommodate Maven CI-friendly versions

Open
#322 4 comments 1 reaction 0 assignees View on GitHub
enhancement priority:major
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.