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

[Joakim Erdfelt-2]

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

Direct usage of the wagon, not through the wagon manager, means a lot
less functionality than desired.

- Joakim

kenney@... wrote:

> Author: kenney
> Date: Wed Jun 20 04:06:27 2007
> New Revision: 549064
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=549064
> Log:
> Restore backwards compatibility - fix the deprecated method.
>
> Modified:
>     maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
>
> Modified: maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
> URL: http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java?view=diff&rev=549064&r1=549063&r2=549064
> ==============================================================================
> --- maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java (original)
> +++ maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java Wed Jun 20 04:06:27 2007
> @@ -197,6 +197,9 @@
>      public void connect( Repository repository, AuthenticationInfo authenticationInfo, ProxyInfo proxyInfo )
>          throws ConnectionException, AuthenticationException
>      {
> +        setRepository( repository );
> +        setAuthenticationInfo( authenticationInfo );
> +        setProxyInfo( proxyInfo );
>          connect();
>      }
>  
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-commits-unsubscribe@...
> For additional commands, e-mail: wagon-commits-help@...
>
>  

--
- Joakim Erdfelt
  joakim@...
  Open Source Software (OSS) Developer


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

[Jason van Zyl-2]

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.

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.

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.

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

> - Joakim
>
> kenney@... wrote:
>> Author: kenney
>> Date: Wed Jun 20 04:06:27 2007
>> New Revision: 549064
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=549064
>> Log:
>> Restore backwards compatibility - fix the deprecated method.
>>
>> Modified:
>>     maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/
>> maven/wagon/AbstractWagon.java
>>
>> Modified: maven/wagon/trunk/wagon-provider-api/src/main/java/org/
>> apache/maven/wagon/AbstractWagon.java
>> URL: http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-provider- 
>> api/src/main/java/org/apache/maven/wagon/AbstractWagon.java?
>> view=diff&rev=549064&r1=549063&r2=549064
>> =====================================================================
>> =========
>> --- maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/
>> maven/wagon/AbstractWagon.java (original)
>> +++ maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/
>> maven/wagon/AbstractWagon.java Wed Jun 20 04:06:27 2007
>> @@ -197,6 +197,9 @@
>>      public void connect( Repository repository,  
>> AuthenticationInfo authenticationInfo, ProxyInfo proxyInfo )
>>          throws ConnectionException, AuthenticationException
>>      {
>> +        setRepository( repository );
>> +        setAuthenticationInfo( authenticationInfo );
>> +        setProxyInfo( proxyInfo );
>>          connect();
>>      }
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wagon-commits-unsubscribe@...
>> For additional commands, e-mail: wagon-commits-help@...
>>
>>
>
>
> --
> - Joakim Erdfelt
>  joakim@...
>  Open Source Software (OSS) Developer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@...
> For additional commands, e-mail: wagon-dev-help@...
>
>

Thanks,

Jason

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




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

[Joakim Erdfelt-2]

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

[Jason van Zyl-2]

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

Thanks,

Jason

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




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