[ http://jira.codehaus.org/browse/MNG-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann closed MNG-4592. ---------------------------------- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Benjamin Bentmann Fixed in [r995606|http://svn.apache.org/viewvc?view=revision&revision=995606]. As suggested, only the not-found case is cached, other transfer errors aren't and will have resolution be retried during the next build. > Snapshot artifacts that could not be downloaded due to communication problems > are "blacklisted" for a day by default. > --------------------------------------------------------------------------------------------------------------------- > > Key: MNG-4592 > URL: http://jira.codehaus.org/browse/MNG-4592 > Project: Maven 2 & 3 > Issue Type: Bug > Affects Versions: 3.0-alpha-7 > Reporter: Marc Wirth > Assignee: Benjamin Bentmann > Fix For: 3.0-beta-4 > > > If an artifact could not be downloaded because of communication problems with > the server Maven should not use the update check intervall before rechecking. > The fix for http://jira.codehaus.org/browse/MNG-3421 introduced a behaviour > that has cost us some time to find a solution. We're facing network problems > with one of our nexus servers and this results by default in a 24 hour > "blacklisting" of that artifact. For a continuous integration scenario this > is rather painful (build stays red for a whole day) and using a different > policy increases the network overhead because then all snapshots are checked. > For now we have a very ugly workaround that simply deletes all *.lastUpdated > files from the local repository. > > A better solution from our point of view would be to only write the > lastUpdated file if the resource really doesn't exist > (DefaultWagonManager#getRemoteFile() threw ResourceDoesNotExistException?), > but not if the wagon reported a communication problem > (TransferFailedException?). That way the solution to MNG-3421 should still be > valid, but without blocking CI in our case. > > It would also be rather helpful if the real cause for such delayed lookups > would be reported by default ("Failure to resolve ... was cached in the local > repository. Resolution will not be reattempted until ..."). In our case we > only had the standard error message in the log that the artifact could not be > resolved from any repository and it took us a while to figure out that this > was really because of the lastUpdated-check. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira