I will rewrite the test to not depend on this method. Thanks everyone
replying!
Brett Porter wrote:
Wagon is resource oriented, rather than artifact oriented - this is
more equivalent to HEAD in HTTP. I don't see a need for it in artifact
handling as it would be determined by metadata. I can't think of
anywhere immediately that it would be used.
I think it makes sense to remove from the integration test as from the
title I can't see any reason it would be related to testing that
specifically.
- Brett
On 28/09/2008, at 8:57 AM, Oleg Gusakov wrote:
I cannot imagine a use case where you would check that artifact
exists in the remote repository and then don't download it. Can you?
Brian E. Fox wrote:
Is there never a case that you care if it's there but don't want to
download it? It seems like the efficiency is in how it's used,
rather than the fact that it exists.
-----Original Message-----
From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent:
Saturday, September 27, 2008 6:33 PM
To: Maven Developers List
Subject: wagon's resourceExists() call efficiency ?
wagon API has a very strange method in it: resourceExists(). And
although it is optional -
org.apache.maven.integrationtests.MavenITmng3703ExecutionProjectWithRelativePathsTest.testForkFromReport()
fails if that method is not present.
Jan and I have been weighting pro and contra of this method in the
Mercury transport API and decided against it as we cannot see where
it gives any advantage over direct GET resource. Indeed - if read
resource fails, it's that same as resourceExists() fails. If read
succeeds, then it's equivalent to sequence: resourceExists();
readResource(); But the latter has a way more network roundtrips
compared to just readResource().
I propose to rewrite the integration test so that it does not fail,
if (optional!) Wagon.resourceExists() is not present. Thus we can
avoid rather costly resourceExists().
Thanks,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
