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]


Reply via email to