maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Wirth (JIRA)" <j...@codehaus.org>
Subject [jira] Created: (MNG-4592) Snapshot artifacts that could not be downloaded due to communication problems are "blacklisted" for a day by default.
Date Tue, 16 Mar 2010 12:44:23 GMT
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

        

Mime
View raw message