This http://jira.codehaus.org/browse/WAGONSSH-42 seems to be the closest.
- Joakim John Casey wrote: > Yeah, that's the sort of thing I wanted to talk about here. I was curious > what was outstanding in terms of non-design bugs that could be addressed > prior to 1.0-final. This would seem to fit the bill...is it assigned > to the > 1.0 version in JIRA? > > /me looks... > > I don't see anything in there that would seem to match, but it's possible > I'm not familiar enough with the issue to find it...unless it's WAGON-71. > > -john > > On 2/28/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: >> >> Before we close out wagon 1.0... >> >> Should we address the recurring scp / permissions issue we have with >> people.apache.org? >> >> - Joakim >> >> John Casey wrote: >> > I think all of these items are great ideas. I think you've done a >> > great job >> > of summing up the major recurring discussions about improving wagon >> > (not to >> > mention a couple of good ideas in there that I haven't heard much >> > about). I >> > wouldn't stand in the way of any of this...except where wagon-1.0 is >> > concerned. >> > >> > IMO, most of this list should be developed post-1.0 (whether that's >> > 1.1 or >> > 2.0 is up for debate, of course; this wouldn't really seem to demand a >> > complete rewrite, which is what I'd expect of a 2.0). I don't see how >> > you're >> > going to make some of these changes without creating a lot more >> backward >> > compatibility issues. If we planned on tackling these things in the >> > 1.0branch, we should have gone through more alphas. IMO, we've missed >> > our >> > chance. >> > >> > I think it's important to remember that the existing wagon api works >> > well in >> > many cases, and for a large number of users. We should declare this >> one >> a >> > success, and move on to implementing the things we learned from it. >> > >> > -john >> > >> > On 2/28/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: >> >> >> >> Just so that we have "Joakim's plans" documented here .... >> >> >> >> Wagon Ideas. >> >> >> >> 1. Add Timeouts. >> >> Question becomes, how do we configure this value? >> >> Per Protocol? or Per Repository? >> >> Do we use the <server><configuration> section in the >> settings.xml >> ? >> >> 2. Add Client Header Identification. >> >> This would only be useful on some protocols (such as http / >> dav), >> >> but completely irrelevant on others. >> >> Jason could use this to track the uptake of specific >> versions of >> >> maven on the repo1.maven.org side. >> >> If we decide to do this for http, we can make it be a separate >> >> request header, or a modification of the USER-AGENT string. >> >> 3. Streaming Wagons. >> >> 4. Limited Wagon Transactions. >> >> This becomes a problem when we have a deploy that modifies the >> >> maven-metadata.xml >> >> 5. Deprecation of repository id / server id as the authentication >> >> binding mechanism. >> >> Use what precisely to bind to? >> >> 1. hostname >> >> 2. hostname:port >> >> 3. protocol://hostname:port >> >> 4. regex of any of the above >> >> 5. all of the above >> >> 6. Whitelists on repositories in pom.xml, based on groupId. >> (don't >> >> bother searching this repository if the groupId doesn't match). >> >> This should help optimize the repository searching. It's >> just a >> >> piece of build optimization, anyone consuming the pom could >> just >> >> as well ignore this optimization with no ill effects. >> >> 7. Password Encryption in the settings.xml >> >> >> >> I welcome discussion. >> >> Big +1 or -1 on any concept above. >> >> >> >> And I realize that the concepts above are not wagon exclusive, but >> >> rather overlap with maven 2.1 too. >> >> >> >> - Joakim >> >> >> >> Trygve Laugstøl wrote: >> >> > John Casey wrote: >> >> >> Hi, >> >> >> >> >> >> I just committed some changes to trunk that should restore >> backward >> >> >> compatibility for using older wagons (at least in the vast >> >> majority of >> >> >> cases). It may still break if there is an older version of a wagon >> >> >> out there >> >> >> that doesn't extend from AbstractWagon (since the Wagon interface >> >> >> picked up >> >> >> like 5 new methods lately). >> >> >> >> >> >> Can we start talking about a Wagon 1.0-final release? What do we >> need >> >> >> to get >> >> >> this done? It looks like the current roadmap only shows 3 >> outstanding >> >> >> issues >> >> >> for the next release. Does anyone have plans for finishing those, >> and >> >> >> are >> >> >> they enough to serve as a basis for a final release? >> >> >> >> >> >> I'm just trying to figure out what plans there are for this, since >> >> >> I'd like >> >> >> to move toward a 2.1-alpha-1 release of maven, and this is going >> >> to be >> >> a >> >> >> prereq. >> >> > >> >> > I say release what Wagon is now as 1.0 (in other words no API >> >> > breakage) and put Joakim's plans into Wagon 2.0. >> >> > >> >> > -- >> >> > Trygve >> >> > >> >> > >> --------------------------------------------------------------------- >> >> > 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]
