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