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 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
