Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.0-alpha-7
-
None
-
None
Description
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.
