[
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
