Mailing-List: contact wagon-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: wagon-dev@maven.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <4679762B.4050109@erdfelt.com>
References: <20070620110628.C79661A981A@eris.apache.org>
 <46796051.2020509@erdfelt.com>
 <36B4845B-A77A-4BA7-B860-B118425D7285@maven.org>
 <4679762B.4050109@erdfelt.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D5750051-7375-4251-8501-20C77A06237D@maven.org>
Content-Transfer-Encoding: 7bit
From: Jason van Zyl <jason@maven.org>
Subject: Re: svn commit: r549064 -
 /maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
Date: Wed, 20 Jun 2007 11:54:44 -0700
To: wagon-dev@maven.apache.org


On 20 Jun 07, at 11:47 AM 20 Jun 07, Joakim Erdfelt wrote:

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

No it wasn't. I use IRC all the time and that doesn't bother me. You  
talked in vague terms and then touched a ton of files. Like I told, I  
wouldn't have cared at all if it worked. But it created a huge mess  
because many things stopped working and not just for IDE integration  
and the C Builds but some basic things like the listeners not being  
attached at all which was a result of making radical changes that  
didn't mesh at all with how it was being used. This is why I'm  
worried about the changes.

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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
For additional commands, e-mail: wagon-dev-help@maven.apache.org