Jason van Zyl wrote:
On 28-Feb-08, at 1:35 PM, Brett Porter wrote:
On 29/02/2008, at 5:51 AM, Jason van Zyl wrote:
I'm going to roll back all the WagonDAV changes as
1) As we discussed about extensions on the list that for deployment
the required libraries necessary for deployment should be
dependencies listed in the deployment plugin and not wired into the
core.
2) The wagons can now be picked up with the dynamic collections so
that's also not necessary to bind them in there.
Is this already in place? The use case is for deploy:deploy-file, so
(1) is not an option.
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the case
for all providers. FTP deploy doesn't work out of the box either,
should be start adding everything because they need a POM to use
deploy file with FTP. Probably not.
The other issue is why isn't just plain PUT fine. I don't know how it
ever came to be that we pushed WebDAV.
Plain PUT does not work if the directory doesn't exist yet. (That's part
of the HTTP spec).
You need something to create the directory (or "Collection" in WebDAV
Terms), this is the MKCOL method.
While it is true that FTP is also a provider, it should be painfully
obvious that all existing repository manager implementations support
WebDAV. And it's a favorite deployment technique in corporate
environments for the security aspects alone.
Sure you could accomplish the same thing with SSH, but how many people
do you find asking for deploy:deploy-file with ssh in the users list?
In many corporations I've been involved in SSH is fine for many tasks,
but not repository management for the rank and file or for the
continuous integration server. (Typically due to political and
maintenance reasonsnot for technical ones)
We have clear trend established with the users (in the mailing list and
jira) that webdav is a popular choice, and the deploy:deploy-file is
painful without it being in core, and also no option to build a custom
client with it embedded (classloader yech, yada yada). bringing it in
via the command line isn't an option. So we're left with creating a pom
just to use deploy:deploy-file with webdav.
As I said before - that's fine, but it should be working before the
first alpha so that there's no regression in functionality.
It's never been there so it's not a regression because no one has ever
used it or done it. If you need a POM to deploy-file that's fine.
We're not going to start pushing in all the providers so people can do
this. Pushing it all in the core, sprinkling the logic everywhere we
need to handle the JARs especially the httpclient mess of commons-* is
not very appealing.
The work that brett did for in wagon-http (not the lightweight one)
cleans up the commons-* stuff significantly (shading the commons-* tree
into the org.apache.maven.wagon.common.* package space). In a local
snapshot build with maven 2.0.x using this new wagon-http over the
existing wagon-http-lightweight found it only added about 300k to the
size of the distro along with making for a more friendly http provider
when dealing with oddball auths, like the one i'm experiencing now that
does not allow for preemptive auth, only challenge / response auth with
the returned cookie from the challenge, or being able to use NTLM auth.
or even being able to use DIGEST auth. something that the
wagon-http-lightweight really does not do effectively.
Then there's also the performance work coming out of Don Brown, which
utilizes the wagon-http provider too.
There is a clear trend and desire for this work / feature. Don't toss
is aside just yet. Lets see where this discussion leads, and lets get
some raw numbers from the mailing list to aide us in the decision.
Meanwhile I'll keep plodding along with the wagon-http infused maven for
a few more weeks to see if anything crops up. (I like it, it seems to
be faster, but I'm sure that's just a subjective perception of it)
3) Merging webdav into the main Wagon is a bad idea. Leave the
simple provider alone and the more complicated ones are easy to add
as dependencies or be loaded dynamically.
I assume you are referring to Joakim's change which is completely
separate and on a branch, and so there's nothing to revert there?
Yup, this is all in a branch, no changes occurred in trunk.
It was created to prove a concept, let discussion start, show that you
can actually bring in the webdav support in a lightweight touch,
_without_ changing the GET / PUT logic in wagon-http, only supplementing
it with a webdav MKCOL for PUT failures and providing a more accurate
file listing in the .fileList() wagon methods for use in the various
plugins that use that method.
I have introduced 1 non-webdav improvement in wagon-http, an improved
LinkParser for html content (using nekohtml + dom + java.net.URI, vs
current trunk which uses jtidy + dom4j + regex)
- Joakim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
