You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <jv...@sonatype.com> on 2009/08/12 23:58:55 UTC
Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
John,
What's the range of features across the two http Wagon's right now?
I assume in some cases we need the functionality of one versus the
other so I would just like to improve the Jetty-client based Wagon and
fix up what's required there, add any functionality and toss the other
two. I would like to have one good implementation and we can take
advantage of the parallelization, PGP, and SSL support in the Jetty
client.
Just trying to figure out what, if anything, is missing from the Jetty
client. If there's anything missing I would like to work on getting
anything in that's missing to have it be present in the 3.0 betas.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
Ok, I'm tracking this here:
http://jira.codehaus.org/browse/MNG-4306
Jesse is going to start implementing this. Sonatype will sponsor the
work and Jesse will implement this on behalf of Webtide so if anyone
has a problem with this let me know.
On 13-Aug-09, at 10:18 AM, Brian Fox wrote:
> Currently the lightweight impl handles NTLMv2 and does a better job
> caching the data when the repository asks for authentication (this one
> uses Sun code). The Sun code has bugs that interfere with uuencoding
> of data in the headers, specifically the passwords. The other wagon
> uses the httpclient, which doesn't support NTLMv2 and doesn't cache
> the data, screwing up the stream observers with repos that need auth.
> It doesn't screw up the data in the headers. So hopefully Jetty will
> support NTLMv2, be smart about handling authenticated repos and not
> screw up the data in the headers.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based
Wagon
Posted by Brian Fox <br...@infinity.nu>.
On Wed, Aug 12, 2009 at 5:58 PM, Jason van Zyl<jv...@sonatype.com> wrote:
> John,
>
> What's the range of features across the two http Wagon's right now?
>
Currently the lightweight impl handles NTLMv2 and does a better job
caching the data when the repository asks for authentication (this one
uses Sun code). The Sun code has bugs that interfere with uuencoding
of data in the headers, specifically the passwords. The other wagon
uses the httpclient, which doesn't support NTLMv2 and doesn't cache
the data, screwing up the stream observers with repos that need auth.
It doesn't screw up the data in the headers. So hopefully Jetty will
support NTLMv2, be smart about handling authenticated repos and not
screw up the data in the headers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>
> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>
>> John,
>
> Not John, but I like to think I do a good impression :)
>
>>
>> What's the range of features across the two http Wagon's right now?
>
> They really don't do anything more than the underlying httpclient /
> JDK implementations. HTTP Headers, connection timeout, and then any
> parameters supported by HTTPClient in that version.
>
>>
>> I assume in some cases we need the functionality of one versus the
>> other so I would just like to improve the Jetty-client based Wagon
>> and fix up what's required there,
>
> I assume you mean the existing mercury-wagon (and its mercury deps),
> not a new wagon based on the underlying jetty http client?
>
>> add any functionality and toss the other two.
>
> shouldn't maven 3 equally support switching implementations and
> instead choosing the new one as a default / only built-in /
> supported impl?
>
>> I would like to have one good implementation and we can take
>> advantage of the parallelization, PGP, and SSL support in the Jetty
>> client.
>
> I'm still not convinced doing the PGP this low down in the stack is
> a good idea, I'd prefer it got fixed up in the core artifact
> handling so it could be configured from the core and used in scp, etc.
>
I'm not convinced anyone cares about anything beyond http/s for
consumption. I think doing one implementation correctly which is
supportable is the first goal. Doing everything and trying to support
everyone is categorically a mistake.
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Three may keep a secret if two of them are dead.
-- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
On 12-Aug-09, at 5:38 PM, Brett Porter wrote:
>
> On 12/08/2009, at 8:14 PM, Jason van Zyl wrote:
>
>> Also I think this is a function of not being able to specify the
>> wagon implementation via URL properly in 2.x. So we'll just find a
>> more normal way to plug in an implementation properly as the core
>> in 3.x is fully dynamic and can load components on the fly.
>
> +1, that's what I meant.
>
>> At any rate it more boils down to a maintenance issue and we have
>> not done a great job maintaining two impls, I don't really see
>> maintaining three of them being a good idea.
>
> Not suggesting that. The HTTP client was never maintained / used
> until recently, and the lightweight one hasn't changed in forever. I
> was suggesting allow lightweight (unmodified), default to/support/
> focus on jetty client going forward.
>
>> I think one good implementation will suffice. The jetty-client is
>> actively develop, better features then other clients and we have
>> Jesse here to help us.
>
> +1
>
> On 12/08/2009, at 8:23 PM, Jason van Zyl wrote:
>
>>>> I would like to have one good implementation and we can take
>>>> advantage of the parallelization, PGP, and SSL support in the
>>>> Jetty client.
>>>
>>> I'm still not convinced doing the PGP this low down in the stack
>>> is a good idea, I'd prefer it got fixed up in the core artifact
>>> handling so it could be configured from the core and used in scp,
>>> etc.
>>>
>>
>> I'm not convinced anyone cares about anything beyond http/s for
>> consumption. I think doing one implementation correctly which is
>> supportable is the first goal. Doing everything and trying to
>> support everyone is categorically a mistake.
>
> That doesn't affect my opinion that it's too far down the stack.
> There's deployment too which is giving us problems when done via a
> plugin. Decision points on whether to accept a signature are not
> just on whether to transport, but whether to use a successfully
> transported artifact (eg, valid signature, but not in this user's
> web of trust). I think this should be sitting in the core around
> calls to get and put (I guess that's inside the repository system
> now).
I'm willing to support PGP in http/s if there is a huge user demand
for it elsewhere. I don't even think users even care to be honest.
It's mostly been implemented because of Noel's nagging. Hank has
already validate no one checks the signatures so while we would
automate that checking if desired I'm perfectly happy to limit it to
http/s. Furthermore I really don't think anything other then http/s
for either retrieving or publishing is popular at all anymore and will
become even less relevant with the prevalence of repository managers.
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Brett Porter <br...@apache.org>.
On 12/08/2009, at 8:14 PM, Jason van Zyl wrote:
> Also I think this is a function of not being able to specify the
> wagon implementation via URL properly in 2.x. So we'll just find a
> more normal way to plug in an implementation properly as the core in
> 3.x is fully dynamic and can load components on the fly.
+1, that's what I meant.
> At any rate it more boils down to a maintenance issue and we have
> not done a great job maintaining two impls, I don't really see
> maintaining three of them being a good idea.
Not suggesting that. The HTTP client was never maintained / used until
recently, and the lightweight one hasn't changed in forever. I was
suggesting allow lightweight (unmodified), default to/support/focus on
jetty client going forward.
> I think one good implementation will suffice. The jetty-client is
> actively develop, better features then other clients and we have
> Jesse here to help us.
+1
On 12/08/2009, at 8:23 PM, Jason van Zyl wrote:
>>> I would like to have one good implementation and we can take
>>> advantage of the parallelization, PGP, and SSL support in the
>>> Jetty client.
>>
>> I'm still not convinced doing the PGP this low down in the stack is
>> a good idea, I'd prefer it got fixed up in the core artifact
>> handling so it could be configured from the core and used in scp,
>> etc.
>>
>
> I'm not convinced anyone cares about anything beyond http/s for
> consumption. I think doing one implementation correctly which is
> supportable is the first goal. Doing everything and trying to
> support everyone is categorically a mistake.
That doesn't affect my opinion that it's too far down the stack.
There's deployment too which is giving us problems when done via a
plugin. Decision points on whether to accept a signature are not just
on whether to transport, but whether to use a successfully transported
artifact (eg, valid signature, but not in this user's web of trust). I
think this should be sitting in the core around calls to get and put
(I guess that's inside the repository system now).
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>
> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>
>> John,
>
> Not John, but I like to think I do a good impression :)
>
>>
>> What's the range of features across the two http Wagon's right now?
>
> They really don't do anything more than the underlying httpclient /
> JDK implementations. HTTP Headers, connection timeout, and then any
> parameters supported by HTTPClient in that version.
>
>>
>> I assume in some cases we need the functionality of one versus the
>> other so I would just like to improve the Jetty-client based Wagon
>> and fix up what's required there,
>
> I assume you mean the existing mercury-wagon (and its mercury deps),
> not a new wagon based on the underlying jetty http client?
>
>> add any functionality and toss the other two.
>
> shouldn't maven 3 equally support switching implementations and
> instead choosing the new one as a default / only built-in /
> supported impl?
>
Also I think this is a function of not being able to specify the wagon
implementation via URL properly in 2.x. So we'll just find a more
normal way to plug in an implementation properly as the core in 3.x is
fully dynamic and can load components on the fly. At any rate it more
boils down to a maintenance issue and we have not done a great job
maintaining two impls, I don't really see maintaining three of them
being a good idea. I think one good implementation will suffice. The
jetty-client is actively develop, better features then other clients
and we have Jesse here to help us.
>> I would like to have one good implementation and we can take
>> advantage of the parallelization, PGP, and SSL support in the Jetty
>> client.
>
> I'm still not convinced doing the PGP this low down in the stack is
> a good idea, I'd prefer it got fixed up in the core artifact
> handling so it could be configured from the core and used in scp, etc.
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
On 12-Aug-09, at 5:27 PM, Brett Porter wrote:
>
> On 12/08/2009, at 8:10 PM, Jason van Zyl wrote:
>
>>
>> On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>>
>>>
>>> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>>>
>>>> John,
>>>
>>> Not John, but I like to think I do a good impression :)
>>>
>>>>
>>>> What's the range of features across the two http Wagon's right now?
>>>
>>> They really don't do anything more than the underlying
>>> httpclient / JDK implementations. HTTP Headers, connection
>>> timeout, and then any parameters supported by HTTPClient in that
>>> version.
>>>
>>>>
>>>> I assume in some cases we need the functionality of one versus
>>>> the other so I would just like to improve the Jetty-client based
>>>> Wagon and fix up what's required there,
>>>
>>> I assume you mean the existing mercury-wagon (and its mercury
>>> deps), not a new wagon based on the underlying jetty http client?
>>>
>>
>> Same thing.
>
> I'm talking about whether it will depend on mercury-core (and sat4j,
> and commons-cli) or just jetty-client. (Or the other alternative to
> pull out the mercury transport bits as a separate release).
>
> Note that the current mercury-wagon hasn't been updated to the
> latest artifacts, I'm not even sure if it builds once updated.
I would just like it to be Jetty client. The SSL and WebDAV are built
into the client and the PGP is as add-on but is essentially just a
stream observer. The mercury effort will be pushed post 3.0. It's too
much to try and and stuff into the 3.0.
>
>>
>>>> add any functionality and toss the other two.
>>>
>>> shouldn't maven 3 equally support switching implementations and
>>> instead choosing the new one as a default / only built-in /
>>> supported impl?
>>>
>>
>> No. I'll take one good with the same features. That's why I'm
>> asking what's in both them. Users just want something that works, I
>> doubt anyone cares about switching unless they run into the corner
>> cases that force them to use one or the other.
>
> Presumably those users with edge cases exist since John went to all
> that effort to make it happen in 2.2.
Those edge cases have to be absorbed and accommodated by the single
client is what I'm saying.
> I'm all for using the Jetty one and I'm sure they'll fix up any edge
> cases as we go, but given how well established the lightweight HTTP
> one is, it might still be worth having that available to start with.
> My impression was that switching would be easier out of the box in
> M3's classloading so it wouldn't be a big deal.
Being able to use any provider is just an order of magnitude easier
with the 3.x core, I just want to ship with the most complete one and
would prefer people not to ever have to look at the other ones because
of deficiencies. But it will be easier to switch implementations in 3.x.
>
>>
>>>> I would like to have one good implementation and we can take
>>>> advantage of the parallelization, PGP, and SSL support in the
>>>> Jetty client.
>>>
>>> I'm still not convinced doing the PGP this low down in the stack
>>> is a good idea, I'd prefer it got fixed up in the core artifact
>>> handling so it could be configured from the core and used in scp,
>>> etc.
>>>
>>> - Brett
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Replacing old Wagons in Maven 3.0 with the Jetty-client based
Wagon
Posted by Jason Chaffee <ja...@zilliontv.tv>.
Yeah, I got that more as I read more of the threads.
Nonetheless, I thought it might be valuable to hear from a couple of users that were just talking about being about to use different implementations.
Thanks for the info though.
Jason
-----Original Message-----
From: Jason van Zyl [mailto:jvanzyl@sonatype.com]
Sent: Wednesday, August 12, 2009 6:34 PM
To: Maven Developers List
Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
On 12-Aug-09, at 5:37 PM, Jason Chaffee wrote:
> It was just yesterday that I was just have a conversation with a
> former colleague about wagon issues in 2.x and the difficulty in
> switching out implementations. He was running into all kinds of
> issues trying to do it and was not very happy about it. Also, this
> is something I have mentioned on the this list in the past about one
> of the things that I find annoying about maven.
>
> I know for a fact, that some people do care about switching and it
> is a bigger populace than is given credit.
>
The discussion is really about what we want to support well versus
pluggability.
Pluggability is easier in 3.x and no work is going to be done on the
sub-systems in 2.x to make that as flexible and we're moving to Guice
anyway so Plexus is dead. So whoever makes implementations of the
retriever or publisher you'll be able to switch more easily in 3.x.
In the case of the components that actually come out of this project
and the use cases we can reasonably support as an OSS project, I want
to start severely constraining that because along with the component
is maintenance, testing and documentation. I think we can reasonably
support one flavor of each major component and do the necessary
ancillary work. I think that will be the impetus for other to make
good implementations of what they want instead of thinking all of our
implementations, many of which just honestly aren't fully baked, are
great.
>
>
> Kind regards,
>
> Jason
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
> Porter
> Sent: Wednesday, August 12, 2009 5:28 PM
> To: Maven Developers List
> Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client
> based Wagon
>
>
> On 12/08/2009, at 8:10 PM, Jason van Zyl wrote:
>
>>
>> On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>>
>>>
>>> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>>>
>>>> John,
>>>
>>> Not John, but I like to think I do a good impression :)
>>>
>>>>
>>>> What's the range of features across the two http Wagon's right now?
>>>
>>> They really don't do anything more than the underlying httpclient /
>>> JDK implementations. HTTP Headers, connection timeout, and then any
>>> parameters supported by HTTPClient in that version.
>>>
>>>>
>>>> I assume in some cases we need the functionality of one versus the
>>>> other so I would just like to improve the Jetty-client based Wagon
>>>> and fix up what's required there,
>>>
>>> I assume you mean the existing mercury-wagon (and its mercury
>>> deps), not a new wagon based on the underlying jetty http client?
>>>
>>
>> Same thing.
>
> I'm talking about whether it will depend on mercury-core (and sat4j,
> and commons-cli) or just jetty-client. (Or the other alternative to
> pull out the mercury transport bits as a separate release).
>
> Note that the current mercury-wagon hasn't been updated to the latest
> artifacts, I'm not even sure if it builds once updated.
>
>>
>>>> add any functionality and toss the other two.
>>>
>>> shouldn't maven 3 equally support switching implementations and
>>> instead choosing the new one as a default / only built-in /
>>> supported impl?
>>>
>>
>> No. I'll take one good with the same features. That's why I'm asking
>> what's in both them. Users just want something that works, I doubt
>> anyone cares about switching unless they run into the corner cases
>> that force them to use one or the other.
>
> Presumably those users with edge cases exist since John went to all
> that effort to make it happen in 2.2. I'm all for using the Jetty one
> and I'm sure they'll fix up any edge cases as we go, but given how
> well established the lightweight HTTP one is, it might still be worth
> having that available to start with. My impression was that switching
> would be easier out of the box in M3's classloading so it wouldn't be
> a big deal.
>
>>
>>>> I would like to have one good implementation and we can take
>>>> advantage of the parallelization, PGP, and SSL support in the
>>>> Jetty client.
>>>
>>> I'm still not convinced doing the PGP this low down in the stack is
>>> a good idea, I'd prefer it got fixed up in the core artifact
>>> handling so it could be configured from the core and used in scp,
>>> etc.
>>>
>>> - Brett
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A language that doesn't affect the way you think about programming is
not worth knowing.
-- Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
On 12-Aug-09, at 5:37 PM, Jason Chaffee wrote:
> It was just yesterday that I was just have a conversation with a
> former colleague about wagon issues in 2.x and the difficulty in
> switching out implementations. He was running into all kinds of
> issues trying to do it and was not very happy about it. Also, this
> is something I have mentioned on the this list in the past about one
> of the things that I find annoying about maven.
>
> I know for a fact, that some people do care about switching and it
> is a bigger populace than is given credit.
>
The discussion is really about what we want to support well versus
pluggability.
Pluggability is easier in 3.x and no work is going to be done on the
sub-systems in 2.x to make that as flexible and we're moving to Guice
anyway so Plexus is dead. So whoever makes implementations of the
retriever or publisher you'll be able to switch more easily in 3.x.
In the case of the components that actually come out of this project
and the use cases we can reasonably support as an OSS project, I want
to start severely constraining that because along with the component
is maintenance, testing and documentation. I think we can reasonably
support one flavor of each major component and do the necessary
ancillary work. I think that will be the impetus for other to make
good implementations of what they want instead of thinking all of our
implementations, many of which just honestly aren't fully baked, are
great.
>
>
> Kind regards,
>
> Jason
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
> Porter
> Sent: Wednesday, August 12, 2009 5:28 PM
> To: Maven Developers List
> Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client
> based Wagon
>
>
> On 12/08/2009, at 8:10 PM, Jason van Zyl wrote:
>
>>
>> On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>>
>>>
>>> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>>>
>>>> John,
>>>
>>> Not John, but I like to think I do a good impression :)
>>>
>>>>
>>>> What's the range of features across the two http Wagon's right now?
>>>
>>> They really don't do anything more than the underlying httpclient /
>>> JDK implementations. HTTP Headers, connection timeout, and then any
>>> parameters supported by HTTPClient in that version.
>>>
>>>>
>>>> I assume in some cases we need the functionality of one versus the
>>>> other so I would just like to improve the Jetty-client based Wagon
>>>> and fix up what's required there,
>>>
>>> I assume you mean the existing mercury-wagon (and its mercury
>>> deps), not a new wagon based on the underlying jetty http client?
>>>
>>
>> Same thing.
>
> I'm talking about whether it will depend on mercury-core (and sat4j,
> and commons-cli) or just jetty-client. (Or the other alternative to
> pull out the mercury transport bits as a separate release).
>
> Note that the current mercury-wagon hasn't been updated to the latest
> artifacts, I'm not even sure if it builds once updated.
>
>>
>>>> add any functionality and toss the other two.
>>>
>>> shouldn't maven 3 equally support switching implementations and
>>> instead choosing the new one as a default / only built-in /
>>> supported impl?
>>>
>>
>> No. I'll take one good with the same features. That's why I'm asking
>> what's in both them. Users just want something that works, I doubt
>> anyone cares about switching unless they run into the corner cases
>> that force them to use one or the other.
>
> Presumably those users with edge cases exist since John went to all
> that effort to make it happen in 2.2. I'm all for using the Jetty one
> and I'm sure they'll fix up any edge cases as we go, but given how
> well established the lightweight HTTP one is, it might still be worth
> having that available to start with. My impression was that switching
> would be easier out of the box in M3's classloading so it wouldn't be
> a big deal.
>
>>
>>>> I would like to have one good implementation and we can take
>>>> advantage of the parallelization, PGP, and SSL support in the
>>>> Jetty client.
>>>
>>> I'm still not convinced doing the PGP this low down in the stack is
>>> a good idea, I'd prefer it got fixed up in the core artifact
>>> handling so it could be configured from the core and used in scp,
>>> etc.
>>>
>>> - Brett
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Replacing old Wagons in Maven 3.0 with the Jetty-client based
Wagon
Posted by Jason Chaffee <ja...@zilliontv.tv>.
It was just yesterday that I was just have a conversation with a former colleague about wagon issues in 2.x and the difficulty in switching out implementations. He was running into all kinds of issues trying to do it and was not very happy about it. Also, this is something I have mentioned on the this list in the past about one of the things that I find annoying about maven.
I know for a fact, that some people do care about switching and it is a bigger populace than is given credit.
Kind regards,
Jason
-----Original Message-----
From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett Porter
Sent: Wednesday, August 12, 2009 5:28 PM
To: Maven Developers List
Subject: Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
On 12/08/2009, at 8:10 PM, Jason van Zyl wrote:
>
> On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>
>>
>> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>>
>>> John,
>>
>> Not John, but I like to think I do a good impression :)
>>
>>>
>>> What's the range of features across the two http Wagon's right now?
>>
>> They really don't do anything more than the underlying httpclient /
>> JDK implementations. HTTP Headers, connection timeout, and then any
>> parameters supported by HTTPClient in that version.
>>
>>>
>>> I assume in some cases we need the functionality of one versus the
>>> other so I would just like to improve the Jetty-client based Wagon
>>> and fix up what's required there,
>>
>> I assume you mean the existing mercury-wagon (and its mercury
>> deps), not a new wagon based on the underlying jetty http client?
>>
>
> Same thing.
I'm talking about whether it will depend on mercury-core (and sat4j,
and commons-cli) or just jetty-client. (Or the other alternative to
pull out the mercury transport bits as a separate release).
Note that the current mercury-wagon hasn't been updated to the latest
artifacts, I'm not even sure if it builds once updated.
>
>>> add any functionality and toss the other two.
>>
>> shouldn't maven 3 equally support switching implementations and
>> instead choosing the new one as a default / only built-in /
>> supported impl?
>>
>
> No. I'll take one good with the same features. That's why I'm asking
> what's in both them. Users just want something that works, I doubt
> anyone cares about switching unless they run into the corner cases
> that force them to use one or the other.
Presumably those users with edge cases exist since John went to all
that effort to make it happen in 2.2. I'm all for using the Jetty one
and I'm sure they'll fix up any edge cases as we go, but given how
well established the lightweight HTTP one is, it might still be worth
having that available to start with. My impression was that switching
would be easier out of the box in M3's classloading so it wouldn't be
a big deal.
>
>>> I would like to have one good implementation and we can take
>>> advantage of the parallelization, PGP, and SSL support in the
>>> Jetty client.
>>
>> I'm still not convinced doing the PGP this low down in the stack is
>> a good idea, I'd prefer it got fixed up in the core artifact
>> handling so it could be configured from the core and used in scp,
>> etc.
>>
>> - Brett
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Brett Porter <br...@apache.org>.
On 12/08/2009, at 8:10 PM, Jason van Zyl wrote:
>
> On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>
>>
>> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>>
>>> John,
>>
>> Not John, but I like to think I do a good impression :)
>>
>>>
>>> What's the range of features across the two http Wagon's right now?
>>
>> They really don't do anything more than the underlying httpclient /
>> JDK implementations. HTTP Headers, connection timeout, and then any
>> parameters supported by HTTPClient in that version.
>>
>>>
>>> I assume in some cases we need the functionality of one versus the
>>> other so I would just like to improve the Jetty-client based Wagon
>>> and fix up what's required there,
>>
>> I assume you mean the existing mercury-wagon (and its mercury
>> deps), not a new wagon based on the underlying jetty http client?
>>
>
> Same thing.
I'm talking about whether it will depend on mercury-core (and sat4j,
and commons-cli) or just jetty-client. (Or the other alternative to
pull out the mercury transport bits as a separate release).
Note that the current mercury-wagon hasn't been updated to the latest
artifacts, I'm not even sure if it builds once updated.
>
>>> add any functionality and toss the other two.
>>
>> shouldn't maven 3 equally support switching implementations and
>> instead choosing the new one as a default / only built-in /
>> supported impl?
>>
>
> No. I'll take one good with the same features. That's why I'm asking
> what's in both them. Users just want something that works, I doubt
> anyone cares about switching unless they run into the corner cases
> that force them to use one or the other.
Presumably those users with edge cases exist since John went to all
that effort to make it happen in 2.2. I'm all for using the Jetty one
and I'm sure they'll fix up any edge cases as we go, but given how
well established the lightweight HTTP one is, it might still be worth
having that available to start with. My impression was that switching
would be easier out of the box in M3's classloading so it wouldn't be
a big deal.
>
>>> I would like to have one good implementation and we can take
>>> advantage of the parallelization, PGP, and SSL support in the
>>> Jetty client.
>>
>> I'm still not convinced doing the PGP this low down in the stack is
>> a good idea, I'd prefer it got fixed up in the core artifact
>> handling so it could be configured from the core and used in scp,
>> etc.
>>
>> - Brett
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Jason van Zyl <jv...@sonatype.com>.
On 12-Aug-09, at 3:43 PM, Brett Porter wrote:
>
> On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
>
>> John,
>
> Not John, but I like to think I do a good impression :)
>
>>
>> What's the range of features across the two http Wagon's right now?
>
> They really don't do anything more than the underlying httpclient /
> JDK implementations. HTTP Headers, connection timeout, and then any
> parameters supported by HTTPClient in that version.
>
>>
>> I assume in some cases we need the functionality of one versus the
>> other so I would just like to improve the Jetty-client based Wagon
>> and fix up what's required there,
>
> I assume you mean the existing mercury-wagon (and its mercury deps),
> not a new wagon based on the underlying jetty http client?
>
Same thing.
>> add any functionality and toss the other two.
>
> shouldn't maven 3 equally support switching implementations and
> instead choosing the new one as a default / only built-in /
> supported impl?
>
No. I'll take one good with the same features. That's why I'm asking
what's in both them. Users just want something that works, I doubt
anyone cares about switching unless they run into the corner cases
that force them to use one or the other.
>> I would like to have one good implementation and we can take
>> advantage of the parallelization, PGP, and SSL support in the Jetty
>> client.
>
> I'm still not convinced doing the PGP this low down in the stack is
> a good idea, I'd prefer it got fixed up in the core artifact
> handling so it could be configured from the core and used in scp, etc.
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Replacing old Wagons in Maven 3.0 with the Jetty-client based Wagon
Posted by Brett Porter <br...@apache.org>.
On 12/08/2009, at 5:58 PM, Jason van Zyl wrote:
> John,
Not John, but I like to think I do a good impression :)
>
> What's the range of features across the two http Wagon's right now?
They really don't do anything more than the underlying httpclient /
JDK implementations. HTTP Headers, connection timeout, and then any
parameters supported by HTTPClient in that version.
>
> I assume in some cases we need the functionality of one versus the
> other so I would just like to improve the Jetty-client based Wagon
> and fix up what's required there,
I assume you mean the existing mercury-wagon (and its mercury deps),
not a new wagon based on the underlying jetty http client?
> add any functionality and toss the other two.
shouldn't maven 3 equally support switching implementations and
instead choosing the new one as a default / only built-in / supported
impl?
> I would like to have one good implementation and we can take
> advantage of the parallelization, PGP, and SSL support in the Jetty
> client.
I'm still not convinced doing the PGP this low down in the stack is a
good idea, I'd prefer it got fixed up in the core artifact handling so
it could be configured from the core and used in scp, etc.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org