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 on
larger sized objects.
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
Not necessarily. I can envision other ways to do this, but this is
probably the way I would do it.
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.
You are assuming that GET is the only thing you ever want to do. The use
case I am concerned about is PUT. If I do mvn deploy I want to do a
request to see if it exists and then do a PUT if it doesn't. Since HEAD
is cheaper than GET in this case that would be preferable.
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.
I understand the argument about why ITs shouldn't fail if a Wagon
provider doesn't implement something. I'm just saying I see no evidence
that resourceExists is actually optional. I have also demonstrated a
use case where resourceExists using HEAD makes more sense than doing a GET.
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.
No, I'm not surprised. setHttpHeaders isn't defined in the Wagon
interface and so is truly optional. resourceExists IS defined there and
is therefore NOT optional.
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?
No. If a method is defined in an interface it is NOT optional. Something
must eventually define the method. Even an abstract method must
eventually being implemented. The only ways a method can be "optional"
is for it NOT to be declared in an interface or for it to be defined as
throwing an exception that indicates to the caller that it is not always
implemented.
But then suddenly you hit an IT that fails, complaining that
"resourceExists() is not implemented by wagon". That is wrong.
No, that is correct for a non-optional method.
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.
My understanding is that the metadata should exist along with the
artifact. Either both should exist or neither. If any of them exist I
shouldn't have to do anything. If any of them do not then the deploy
didn't succeed. Ideally all these items should be deployed to the
repository as one atomic operation. I realize that that is not the case
today (and is precisely why I've heard proposals to replace the
repository with a database).
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
