Re: Plans for Wagon-1.0 final release?

> 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 <joakim@...> 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 <joakim@...> 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: wagon-dev-unsubscribe@...
>> >> > For additional commands, e-mail: wagon-dev-help@...
>> >> >
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
>> For additional commands, e-mail: wagon-dev-help@...
>>
>>
>