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 no a valid use case of HEAD, not
followed by GET.
The deploy plugin checking for a released artifact present in a remote
repo, does not stand, in my opinion, as HEAD A-V.jar should instead be
GET a maven-metadata.xml and check for V there. It's more efficient because:
* if V is not in metadata, deploy plugin will have to read metadata
anyway
* if V is already in metadata, we did not loose too much.
If in 50% cases artifact is not present - we save a lot of network
rountrips (GET that will follow that HEAD). Even if it's ot present in,
say 20% cases - we by far compensated for the difference between HEAD
and GET metadata.xml. Additional consideration: metadata.xml is
relatively small, and will fit in the same ip packet as response for
HEAD thus producing no difference at all.
On average - not having HEAD improves efficiency of repository lookup.
Thanks,
Oleg
Taking it away simply because someone could be dumb doesn't sense,
especially since we already have on valid use case for it.
Sent from my iPhone
On Sep 29, 2008, at 12:12 PM, Oleg Gusakov
<[EMAIL PROTECTED]> wrote:
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
implementation choice for the author of the resourceExists method,
not the author of the deployer code.
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.
If resource exists and you want it
1. you have to send a GET request - second network trip to get contents
2. you already are receiving the contents
So in reality - there is no benefit in separating the
resourceExists() and resourceGet() on transport level. I don't argue
it's existence in above transport layers: implement it as transport's
getResource() and wait for failure.
But wagon IS our transport layer, and it tries to impose higher level
call to lower level protocol. It should stay in the Wagon APIs, and
if wagon provider does not implement it - integration tests should
not fail. This is what this argument is about.
Next, I admit, I haven't looked much at the Wagon classes. But I
glanced at
https://svn.apache.org/repos/asf/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/Wagon.java.
I don't see anything in the javadoc indicating the method is
optional. A search for wagon site:maven.apache.org didn't yield
anything either. In fact, it is hard to imagine how it could be
since it returns a boolean and the only documented Exceptions are
TransferFailedException and AuthorizationException. I would expect
to see UnsupportedOperationException at least mentioned if it was
optional.
You'll be surprised to learn, that another optional method
"setHttpHeaders()" is discovered via reflection, and cause 2 or 3
tests fail if it does not exists! I found it so obviously wrong that
I did not mention it in the discussion.
So please tell me where this method is described as optional.
If you use Wagon way of writing providers and inherit from
AbstractWagon, you are good to go without too much trouble. To me -
it's optional. Although in AbstractWagon there are several methods
like this - they throw Unsupported... exception if called. ITs only
call this one.
Normally - if you want to mandate something - declare it abstract,
right?
But then suddenly you hit an IT that fails, complaining that
"resourceExists() is not implemented by wagon". That is wrong.
Finally, Yes, I use Nexus and I would also want it to be able to
enforce this, but it should really be built into Maven. I'm a
little unclear why you are saying Maven should update the metadata
for an already deployed artifact.
You don't have to update metadata for a deployed release, but you
should check it's existence in the metadata. Because if it exists,
you don't have to do anything, if it does not - you already have
metadata and can modify it and send back, together with the artifact.
Thanks,
Oleg
Ralph
Oleg Gusakov 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 metadata, or metadata read failed it's equivalent
to resource does not exist, but now you have much more information
to act upon.
Ralph Goers wrote:
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?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
