Repository navigation
Maven wrapper caching does not seem to cache enough #1095
Description
Description:
setup-java was recently modified (2 weeks ago) to also cache Maven distributions used by the mvnw wrapper script. See #1027.
JRuby's build uses setup-java@v5 but 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@v5 as of the time of the above build.
Platform:
- Ubuntu
- macOS
- Windows
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:
- Hosted
- Self-hosted
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: maven and setup-java@v5 so 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.
Activity
headius commentedon Jul 9, 2026
See JRuby issue jruby/jruby#9493 which led us to start exploring how to make
mvnwmore reliable.brunoborges commentedon Jul 10, 2026
@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:A few notes:
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.Appreciate any results you can share.
Address cache.ts review feedback
chadlwilson commentedon 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.
brunoborges commentedon Jul 10, 2026
@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.[1] https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#ensuring-the-maven-cache-is-complete-plugin-dependencies
Cache Maven and Gradle wrapper distributions separately from the depe…
Backport #1097/#1098: cache Maven and Gradle wrapper distributions se…
headius commentedon Jul 14, 2026
Hey @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.
brunoborges commentedon Jul 14, 2026
Thanks @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
Use setup-java with fixed maven wrapper caching
headius commentedon Jul 20, 2026
@brunoborges I neglected to mention it here but the linked PR tested successfully against the V5 release branch.
brunoborges commentedon Jul 20, 2026
Awesome, thanks @headius . V5.6 is released with the fix now