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]


Reply via email to