The other problem with dropping it into the distribution is that when
we find out there is a bug in it you can't simply specify a new
version of the provider, you would have to go replace the provider and
all its deps, or make your own shaded JAR which would be a pain in the
ass.
On 29-Feb-08, at 12:22 PM, Brian E. Fox wrote:
+1 to putting in on the url, that's a muuuch better solution and works
for all wagons, not just webdav.
-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 2:25 PM
To: Maven Developers List
Subject: Re: Wagon changes and WebDAV
On 28-Feb-08, at 9:58 PM, Joakim Erdfelt wrote:
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.
This is so simple to add to something like Jetty, my concern is that
the WebDAV implementations are so crappy that I've backed away from it
as a viable solution. Try running litmus
(http://www.webdav.org/neon/litmus/
) against any of them and they fail miserably. At least the Java ones,
and when I mean terrible I mean 60-70% compliant terrible. Andy and
Tamas worked a long time on our to try and make it compliant and in
the end I don't think it was worth it. It's also just so horrendously
slow. The Java implementations are just not that good. So that's
probably the crux of my argument. What is there that's better? A
simple addition to the PUT handler in Jetty and you have deployment.
At any rate as I will say below we can have a lean core and
convenience.
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)
I will show you that it's not necessary to put it in the core to make
it easy for people to deploy things. What will the user always have to
provide to deploy? The URL? With the URL we can determine the provider
(if we can't we have to fix that), and with the provider we can
dynamically download and load whatever is necessary with out hassling
the user. It all doesn't need to go into the core.
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 described above we have all the information we need to make it easy
and not bloat the core.
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)
Not saying that it shouldn't be possible to deploy:deploy-file. It
should be convenient and work for all protocols. Not half measures for
specific protocols. That it's dumped into 2.0.x I'm not overly
concerned because we're never going to upgrade the container there.
But it's fully possible to have convenience and completeness in 2.1.x
and it's so far away from prime time we don't need to bloat out the
core. The concern are the folks using 2.0.x and that's perfectly
reasonable to satisfy. Make it easy for them and it will be the same
in 2.1.x just implemented in a less core-bloating fashion.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
--Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
