I apologize for dragging this out.
I looked at AbstractWagon and do see that it implements resourceExists
by throwing the UnsupportedOperationException. For clarity this really
should be declared in the Wagon interface even though it is a
RuntimeException. I also looked at all the existing
this sort-of optional
method, let's just make it clear and make it required.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 3:33 AM
To: Maven Developers List
Subject: Re: wagon's resourceExists() call efficiency ?
I apologize for dragging
I'm not sure I understand. If I was to implement this I would imagine
that the deployer would want to call resourceExists() to find out
whether to deploy or not. The fact that resourceExists() can check the
metadata vs the actual file would seem to me to be an implementation
choice for the
Ralph Goers wrote:
I'm not sure I understand. If I was to implement this I would imagine
that the deployer would want to call resourceExists() to find out
whether to deploy or not. The fact that resourceExists() can check the
metadata vs the actual file would seem to me to be an
See below.
Oleg Gusakov wrote:
Think how resourceExists() could be implemented by http provider:
1. send HEAD and look for 404
2. send GET and look for 404
If resource does not exist, you get one network roundtrip in both.
Yes, but HEAD doesn't return the data so will be more efficient
Oleg you are mixing the use of this method with the method being
inefficient. Executing head is not ineficient so there's no reason to
exclude it in the new wagon. Taking it away simply because someone
could be dumb doesn't sense, especially since we already have on valid
use case for it.
I implemented this method to pass ITs, it's existence is off the table.
Brian Fox wrote:
Oleg you are mixing the use of this method with the method being
inefficient. Executing head is not ineficient
Agree
so there's no reason to exclude it in the new wagon.
Don't agree - as there still is
Not all artifacts can be discovered via metadata so it's not safe to
assume you can always check there.
Sent from my iPhone
On Sep 29, 2008, at 10:08 PM, Oleg Gusakov
[EMAIL PROTECTED] wrote:
I implemented this method to pass ITs, it's existence is off the
table.
Brian Fox wrote:
Oleg
Brian Fox wrote:
Not all artifacts can be discovered via metadata so it's not safe to
assume you can always check there.
Classifiers? Same argument: GET vs. HEAD, followed by GET. I cannot
imagine a use case where one would check that -sources.jar exists in the
remote repo without downloading
Perhaps. Except that resourceExists is still NOT an optional method. If
you change it so that it is you might as well just remove it entirely.
The whole point of the method is to use a less expensive method to check
if the resource exists. By allowing it to through an exception and force
the
Man, I did not want to talk about this any more .. but cannot help it,
as this is about a second half of the issue.
Ralph Goers wrote:
Perhaps. Except that resourceExists is still NOT an optional method.
If developer follows a stable dev. pattern, in this case: create a new
wagon provider by
what about preventing redeployment of non-snapshots?
Sent from my iPod
On 27 Sep 2008, at 23:57, Oleg Gusakov [EMAIL PROTECTED]
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:
But this information comes from repository metadata, not from probing
the actual file. If it does - repository integrity is broken, isn't it?
Deploy should read the metadata anyway as it is supposed to update [in a
dumb http/dav repository, Nexus can do it for us], so if version is not
in
Stephen - please see my reply to Ralph's question; same use case.
Stephen Connolly wrote:
what about preventing redeployment of non-snapshots?
Sent from my iPod
On 27 Sep 2008, at 23:57, Oleg Gusakov [EMAIL PROTECTED]
wrote:
I cannot imagine a use case where you would check that artifact
To: Maven Developers List
Subject: Re: wagon's resourceExists() call efficiency ?
But this information comes from repository metadata, not from probing
the actual file. If it does - repository integrity is broken, isn't it?
Deploy should read the metadata anyway as it is supposed to update [in a
dumb
List
Subject: Re: wagon's resourceExists() call efficiency ?
But this information comes from repository metadata, not from probing
the actual file. If it does - repository integrity is broken, isn't
it?
Deploy should read the metadata anyway as it is supposed to update
[in a
dumb http/dav
resourceExists() call efficiency ?
But this information comes from repository metadata, not from probing
the actual file. If it does - repository integrity is broken, isn't it?
Deploy should read the metadata anyway as it is supposed to update [in a
dumb http/dav repository, Nexus can do
+1
On 27-Sep-08, at 6:33 PM, Oleg Gusakov wrote:
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
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
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
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
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
Yes. I would actually like the deploy plugin to NOT deploy a
non-SNAPSHOT artifact if it is already there.
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?
23 matches
Mail list logo
