DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Securing CI/CD Pipelines Against Supply Chain Attacks: Why Artifacts and Dependencies Matter More Than Ever
  • Tracking Dependencies Beyond the Build Stage
  • Automating Maven Dependency Upgrades Using AI
  • Implement Hibernate Second-Level Cache With NCache

Trending

  • Detecting Bugs and Vulnerabilities in Java With SonarQube
  • 11 Agentic Testing Tools to Know in 2026
  • AI Agents in Java: Architecting Intelligent Health Data Systems
  • Bringing Intelligence Closer to the Source: Why Real-Time Processing is the Heart of Edge AI
  1. DZone
  2. Data Engineering
  3. Data
  4. How to Resolve Maven's ''Failure to Transfer'' Error

How to Resolve Maven's ''Failure to Transfer'' Error

Learn how to resolve the ''failure to transfer'' error encountered in Maven in this quick tutorial.

By 
Jose Roy Javelosa user avatar
Jose Roy Javelosa
·
Sep. 24, 14 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
129.8K Views

Join the DZone community and get the full member experience.

Join For Free

Here is a quick solution for those encountering the “Failure to Transfer” error in Maven.
The error message will most likely look something like this


Failure to transfer <DEPENDENCY> from <REPOSITORY>
was cached in the local repository, resolution will not be reattempted until 
the update interval of central has elapsed or updates are forced.

This is a documented issue in Maven’s jira page.

When an artifact is unable to be downloaded, Maven 3 caches this result for future reference in the “~/.m2/repo/…/<artifact>.lastUpdated” file. For “not found” situations, it seems that the HTTP code could be used to more granularly re-attempt retrieval rather than just cache the failure.

For example, for any 404, I agree, the result should cache the failure and require a -U to attempt to retrieve it again. However, for 400, 500, 501, 502, 503, 301, 302 (what’s the Maven behavior for 3xx today?) I think the resolution engine should try to re-retrieve the artifact each time. With those error codes, it seems more likely a config issue or brief network hiccup, not one of the file being absent from that repo. However, that brief network hiccup has longstanding cache implications in that the file is never attempted to be retrieved again.

The easiest way to resolve this is to delete the dependencies or artifacts which maven has appended with the .lastUpdated prefix.  Only after that can you successfully Update Dependencies of your maven project.
But deleting all these artifacts from your maven repository one by one every time this occurs is not an ideal solution.
The most simple solution is suggested by Jonas Anderson in Stackoverflow.

For Unix Users

  1. find ~/.m2  -name "*.lastUpdated" -exec grep -q "Could not transfer" {} \; -print -exec rm {} \;
  2. Right click your project and choose Update Dependencies

For Windows

  1. CD (change directory) to
    <user-directory>\.m2\repository
  2. execute this command
    for /r %i in (*.lastUpdated) do del %i
  3. Right click your project and choose Update Dependencies
Apache Maven Cache (computing) Dependency Artifact (UML) Error message Network JOnAS Del (command)

Published at DZone with permission of Jose Roy Javelosa. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Securing CI/CD Pipelines Against Supply Chain Attacks: Why Artifacts and Dependencies Matter More Than Ever
  • Tracking Dependencies Beyond the Build Stage
  • Automating Maven Dependency Upgrades Using AI
  • Implement Hibernate Second-Level Cache With NCache

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook