maven-wagon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <>
Subject Re: svn commit: r549064 - /maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/
Date Wed, 20 Jun 2007 18:47:07 GMT
Jason van Zyl wrote:
> On 20 Jun 07, at 10:13 AM 20 Jun 07, Joakim Erdfelt wrote:
>> Be sure that this doesn't break forward compatibility too.
>> That approach would not allow for proper mirroring, authentication 
>> propagation, network proxy usage, and short-circuits the whole wagon 
>> manager approach of wagon 2.x
> Why is there any concept of mirroring in Wagon.
> You are basically deciding all this stuff on your own and making 
> changes based on what you need in Archiva.
That's nice.
But there's no mirroring in Archiva.  Nor is there any need for it.
Archiva actually uses wagon 1.x, not wagon 2.x or the wagon-manager.
> There's pretty much zero discussion surrounding all the changes you 
> are making and if you expect that to be absorbed into Maven you're 
> going to have a hard sell after what happened the last time it was 
> attempted. If the APIs are not compatible while the code is improved I 
> will be -1 on its inclusion in any version of Maven. There is no 
> reason the changes cannot be more gradual, and made to work with 1.x, 
> 2.0.x, 2.1.x.
Zero?  Hardly.

The discussion for those changes were made in irc a full 5+ months ago.
Regrettably it was not discussed in an archived format, like here in the 
mailing list.
We've all got this disease.  We all have to resolve to change this behavior.
> I'm honestly not in favor of using something so divergent as it's 
> being driven by the use of one application, we'll have a hard time 
> getting it to work right in Maven and we're going to very much screw 
> Maven 1.x because we're yet again going to change/fix everything on 
> something completely different then what they using. This is 
> especially important now that Maven 1.1 is imminent.
The decision was made to ...
a) Consolidate the myriad of usages for wagon into a single point.
b) Not duplicate code within maven client + wagon + plugins to 
accomplish the same task.
c) Give everyone a consistent interface, to get the full benefits of 
authentication + mirroring + network proxying (which currently is 
implemented differently with every usage of wagon)
d) Fix the numerous bugs present in wagon.

>> Direct usage of the wagon, not through the wagon manager, means a lot 
>> less functionality than desired.
> This is what Wagon was made for which is why the WagonManager was 
> always in Maven itself. The manager capability is nice, I agree, but 
> is not of prime importance in Wagon. The prime important is a simple 
> API for transport that works well for each of the providers. I fear 
> the API is going to get out of control like many of our other APIs 
> because the complexity of having this to work in something like 
> Archiva is going to pull in another kitchen sink.
I never proposed eliminating the direct wagon impl usage / use case.
Just make everyone that decides to use it that way aware that they have 
*MORE* work ahead of themselves in order to be consistent with wagon 
usage everywhere else in maven client.

- Joakim

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message