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
Newsletter
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

  • Applying Microservices Lessons to Multi-Agent AI Systems
  • Beyond the Endpoint: How Agent Cards Enable Discovery, Interoperability, and Trust
  • Delta Lake UniForm to Snowflake: Cross-Platform Table Access Without a Second Copy
  • Google Cloud KMS vs. AWS KMS: Java Encryption Guide

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  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
·
Sep. 24, 14 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
130.5K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

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

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • 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