Re: svn commit: r549064 - /maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java

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