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: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
