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