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