Repository navigation
Maven wrapper caching does not seem to cache enough #1095
Description
Activity
See JRuby issue jruby/jruby#9493 which led us to start exploring how to make
mvnwmore reliable.Reacted by Bruno Borges@headius I opened #1097 with a fix. Root cause: the Maven wrapper distribution (
~/.m2/wrapper/dists) was cached in the same entry as~/.m2/repository, keyed on**/pom.xml(+ wrapper props + extensions). Since poms change constantly and there are intentionally norestoreKeys(#269), almost every change was a full cache miss, somvnwre-downloaded Maven and hit the intermittent rate-limit failures. In your failing run I sawmaven cache is not foundfollowed bywget: Failed to fetch .../apache-maven-3.9.14-bin.zip.The PR gives the wrapper distribution its own cache entry keyed only on
**/.mvn/wrapper/maven-wrapper.properties, so it survives pom.xml changes.Would you be able to test it? You can pin
setup-javato the PR commit:- uses: actions/setup-java@6cd4d8602abcb93d479ac1a322ebf80166d853e6 with: distribution: temurin java-version: '21' cache: maven
A few notes:
- The first run after switching won't benefit yet (it needs to populate the new
setup-java-<os>-<arch>-maven-wrapper-<hash>cache entry). Let it run once, then check that subsequent runs, especially ones that modify apom.xml, logCache restored from key: ...for the wrapper and no longer download Maven viamvnw. - Old caches from the previous shared key are harmless and will age out.
- SHA pinning is safest since the branch ref may change as the PR evolves.
Appreciate any results you can share.
Reacted by Chad Wilson- The first run after switching won't benefit yet (it needs to populate the new
- added a commit that references this issue
on Jul 10, 2026 To be fair, in the failing run above, the download URL of the wrapper itself was changed as an experiment, so if the hash is on the content of files (which it seems it is, correcting my own earlier understanding here), it was never going to be cache-loading the Maven distribution in that PR build itself - so perhaps not a great example.
Nevertheless, separating the distribution would probably be helpful, given
mvnwseems to be rather flaky when inscriptmode (wgetonly) in ways normal maven dependency resolution is not, and gives you no feedback by default to even know why the download failed.The bigger question of re-downloading every single dependency for any single text change in any POM is probably still a bit of an issue for a project like JRuby, but I suppose the workaround to that is to consolidate centralised dependency definitions somewhere, and then set
cache-dependency-pathto that single POM, rather than "all POMs" ?We'd probably need to look at
https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#ensuring-the-maven-cache-is-complete-plugin-dependencies to look for other improvements in JRuby, avoid cache population races for parallel jobs and other cache churn.Reacted by Bruno Borges@chadlwilson yeah, separating the caches is a good step forward here nonetheless.
As for your bigger question, indeed it is really up to you how to better organize your dependency graph for caching purposes. Because of how caching works on GitHub Actions, we can't increment caches without overly complicating things (caches are immutable; in practice, a new cache has to be created and referenced, and the old ones expire) and likely result on higher cost for cache usage.
The use of
cache-dependency-pathwith a seed job or step [1] is probably the best solution here. The only other solution is a highly customized workflow with your own caching logic.Reacted by Chad WilsonHey @brunoborges thanks for looking into this. That's exactly what I assumed was happening, and I'm glad to see there's an easy fix.
Reacted by Bruno BorgesThanks @headius . I'll push a new release later this week, but if you can, please test by pointing to the latest commit hash in releases/v5 branch
- added a commit that references this issue
on Jul 16, 2026 @brunoborges I neglected to mention it here but the linked PR tested successfully against the V5 release branch.
Reacted by Bruno BorgesAwesome, thanks @headius . V5.6 is released with the fix now
Description:
setup-java was recently modified (2 weeks ago) to also cache Maven distributions used by the
mvnwwrapper script. See #1027.JRuby's build uses
setup-java@v5but we are still seeing failed downloads of the distribution. We would expect this to have been cached long ago, either by us or by other projects, so this is unexpected.See a failure as recently as yesterday, associated with a PR to attempt to reduce these failures: https://github.com/jruby/jruby/actions/runs/28970521797/job/85964762963
Task version:
setup-java@v5as of the time of the above build.Platform:
I know we see it on Ubuntu, but I believe it has affected builds on other platforms as well. It does not appear to be specific to any platform.
Runner type:
Repro steps:
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
The build below shows a failed mvnw wrapper download that killed a JRuby CI job.
https://github.com/jruby/jruby/actions/runs/28970521797/job/85964762963
Expected behavior:
We use
cache: mavenandsetup-java@v5so we expected that the wrapper would not be downloaded from Maven Central and would not trigger this error.Actual behavior:
As others have reported, rate-limiting or similar restrictions at the Ruby Central level appear to be causing mvnw dist downloads to fail occasionally. We want to use setup-java caching to prevent re-downloading of this distribution, since it almost never changes. That does not appear to be happening.