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


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

        

Reply via email to