Maven Wagon issues

[Trygve Laugstøl <tr...@apache.org>]

Hi

While working on Continuum I've come over a few issues. 

*) DefaultWagonManager requires a AuthenticationInfoProvider. 

As a embedder I shouldn't have to specify a authentication provider if
it's not required for my usage. There should probably be a list of
authentication information providers so a application could add it's own
providers.

Another thing that struck me with the AuthenticationInfoProvider
interface is that the implementation actually can (and is expected to)
change the given wagon Repository. I don't think this is the best way to
do it, you'd probably like to be able to show this object to the user at
a later point in time. What I think that should be done (after 5 minutes
of thinking) is that the configureAuthenticationInfo() should be renamed
to getAuthenticationInfo() and then return a AuthenticationToken which
can be used as a argument to the other Wagon methods.

*) UserModelUtils

This class should be a component. While the Maven CLI executable can
assume that the users configuration is in ~/.m2/user.xml Continuum
really cannot because it needs to be able to control the repository
location from some other configuration mechanism (either console or a
configuration file).

Have a blast!

--
Trygve

Re: Maven Wagon issues

[John Casey <jd...@commonjava.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Trygve and I have already discussed this to some extent on IRC, but I'm
recapping here to ensure everyone is informed. :)

Trygve Laugstøl wrote:
> Hi
> 
> While working on Continuum I've come over a few issues. 
> 
> *) DefaultWagonManager requires a AuthenticationInfoProvider. 
> 
> As a embedder I shouldn't have to specify a authentication provider if
> it's not required for my usage. There should probably be a list of
> authentication information providers so a application could add it's own
> providers.
> 
> Another thing that struck me with the AuthenticationInfoProvider
> interface is that the implementation actually can (and is expected to)
> change the given wagon Repository. I don't think this is the best way to
> do it, you'd probably like to be able to show this object to the user at
> a later point in time. What I think that should be done (after 5 minutes
> of thinking) is that the configureAuthenticationInfo() should be renamed
> to getAuthenticationInfo() and then return a AuthenticationToken which
> can be used as a argument to the other Wagon methods.

While I definitely agree that it's a Bad Idea to have anything mutate
the wagon repository after it's constructed, I don't think the right
solution is to pass around AuthenticationToken's as a sibling object.
Conceptually, a repository has some authentication mechanism (or not,
but that should also be obvious). This is part of the repository access
information, the same way that the host is. If anonymous access is
what's called for, then it should be obvious by looking at the repo
instance that we're using anonymous auth, and we didn't simply lose the
auth token instance that should have accompanied the repo.

This is an integral part of wagon, IMO. If we can't assume that a
repository has authentication information, we'd be hacking wagon to have
ssh support. Even embedders should determine whether they will provide
"full" wagon support - i.e. whether they will supply some active
provider of authentication information. If not, that's something that
should be documented in their application.

I think that whatever is in charge of constructing Repository instances
should have to be aware of an AuthenticationInfoProvider, and call this
to get the auth tokens to be passed into the repository constructor. If
there is no authentication info, or the embedder is only providing
support for anon repository access, then we can retain a constructor
that doesn't deal with auth stuff...sets it 'null' in the repo instance.

> 
> *) UserModelUtils
> 
> This class should be a component. While the Maven CLI executable can
> assume that the users configuration is in ~/.m2/user.xml Continuum
> really cannot because it needs to be able to control the repository
> location from some other configuration mechanism (either console or a
> configuration file).
> 

I agree 100% with this. It was a hack to get some working code out the
door...I'll fix.

> Have a blast!
> 
> --
> Trygve
> 
> 
> 
> 


- -john
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCNfyhK3h2CZwO/4URAiMfAJwJYXV5QnFZppy9vtzFUwXsWv813gCfb4Kg
036haDUcHejqaHz5owLqvc0=
=VfTX
-----END PGP SIGNATURE-----