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]
