+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]
