Just some thoughts. I would like to change wagon-webdav's protocol definition.
Currently it is "dav:http://"; and "dav:https://"; both of which are technically invalid protocols. It should be "dav://" and "davs://". I've wanted to make the wagon's register URL handlers for themselves too. That would allow for a more natural Streaming Wagon implementation too. - Joakim Joakim Erdfelt wrote: > The changes to wagon are ... (just to make sure they show in john's > gmail account) > > 1) Timeouts > 2) Streaming Wagon > 3) Limited Transactions > > - Joakim > > John Casey wrote: > >> Hi all, >> >> I have something to point out that I think the entire Maven development >> community needs to hear. I've been doing a lot of work recently with >> Maven >> trunk, so I notice any (perhaps inevitable) instability that comes >> down the >> pike from dependency APIs. Recently, I've been having a LOT of trouble in >> this area. >> >> Particularly in the Wagon API. It seems that a change was rolled into >> wagon-provider-api around the beginning of February that introduced >> some new >> methods into the Wagon interface. This is not in itself a problem, even >> though the current code version is at 1.0-*beta*-3-SNAPSHOT. What >> causes an >> issue is the fact that these new methods are then assumed to be in >> place by >> the new DefaultWagonManager, effectively breaking that manager's backward >> compatibility with previous releases of Wagon providers. >> >> I tracked all of this down over the course of the past few days, in >> between >> doing the things that I'm actually focused on doing. I can fix this one >> problem by myself; I'm not pleading for help here. However, I cannot >> act as >> the gatekeeper for all APIs that get used in Maven trunk, to ensure their >> stability and backward compatibility. I've been informed that there >> are many >> other such changes heading for Wagon...interestingly enough, a quick >> search >> of my GMail account doesn't turn up any discussion of these changes >> (unless >> it's buried in the deep past somewhere). >> >> I know that this email can look a bit hypocritical on its face, but I >> really >> do feel that we owe it to our user base to be a little more proactive in >> ensuring backward compatibility than we have in the past. I understand >> that >> many Maven developers are on various deadlines, but those deadlines do >> not >> originate in the Maven ASF project, and shouldn't cause undue harm to the >> community or its code. I'm not trying to say we need to rigidly adopt and >> conform to some process or other, but we each individually need to take >> responsibility for discussing and testing any major changes we plan to >> put >> into Maven or its dependencies. >> >> IMHO, pushing new features into a beta API is irresponsible unless you >> can >> be ABSOLUTELY certain it will not impact backward compatibility. In these >> cases, it is my understanding that the normal practice is to create a >> final >> release of the existing API, and then push these bigger changes into the >> next version. >> >> If there's even a shadow of doubt about what effect a change will have on >> the user community, we need to make a serious effort to start a >> discussion >> about it on this list. >> >> >> Regards, >> >> John >> >> > > > --------------------------------------------------------------------- > 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]
