#704: Remove WagonManager

[jarmoniuk]

Removing legacy WagonManager and going forward with Transporter from https://maven.apache.org/resolver/index.html

Advantage: multiple transporter providers possible, not just the default Wagon. Also, future-proof.

it-transporter-002 is testing FileTransporter instead of the default Wagon.

[jarmoniuk]

@slawekjaranowski please review

[slawekjaranowski]

I'm not sure if we can use Resolver Transports in such way.
Rather it is for internal use by Resolver.

In this case - we simply need download a resource from remote url.
Better will be use eg HttpClient from HttpComponents.

[jarmoniuk]

Hmm, are you sure? If that is the case, then I'll provably need to use different transports depending on protocol (file, classpath, etc).

[slawekjaranowski]

@cstamas - can have a best knowledge about it.

[jarmoniuk]

If not, HttpClient5 is lightweight enough and I'd like to use the Fluent flavour of it, if you don't mind.

[jarmoniuk]

Posted a question to dev@maven.apache.org, but I can't see it. Do I need an invite?

[jarmoniuk]

I was thinking of something like that actually. E.g. provide several implementations per protocol (classpath, file, http/https) and use a factory method to select the matching implementation from a map.

Or use Wagon without WagonManager instead? Since Wagon basically already provides such a tnin layer, currently using HttpClient 4.5. Is Wagon going to be retired altogether?

[jarmoniuk]

@hboutemy Do you know if we can continue to use Wagon or is it going to be retired and we should be using e.g. HttpClient directly?

[slawekjaranowski]

Posted a question to dev@maven.apache.org, but I can't see it. Do I need an invite?

You should first subscribe to list.

[jarmoniuk]

I tried, but am not getting the confirmation link.

[slawekjaranowski]

? should works .... after send email to: dev-subscribe at maven.apache.org

[jarmoniuk]

Still waiting for an answer whether we can simply use Wagon (without WagonManager from maven-compat). Note that there's also a org.apache.maven.repository.legacy.WagonManager, of which I don't know whether it's going to be deprecated or not. Hence my question about Wagon in general.

For the time being, I'm still working on a version using HttpClient (largely based on Wagon), but I think I'll also create a version using Wagon only while waiting for the answer.

E.g.

mavenSession.getSettings().getProxies()
        .stream()
        .filter( Proxy::isActive )
        .filter( proxy -> ofNullable( proxy.getProtocol() )
                .map( p -> p.equals( uri.getScheme() ) )
                .orElse( true ) )
        .filter( proxy -> ofNullable( proxy.getNonProxyHosts() )
                .map( s -> s.split( "\\|" ) )
                .map( a -> Arrays.stream( a )
                        .noneMatch( s -> s.equals( uri.getHost() ) ) )
                .orElse( true ) )
        .findAny()
        .ifPresent( proxy ->
        {
            builder.setProxy( new HttpHost( proxy.getProtocol(), proxy.getHost(), proxy.getPort() ) );
            if ( !isBlank( proxy.getUsername() ) && !isBlank( proxy.getPassword() ) )
            {
                builder.setDefaultCredentialsProvider( new BasicCredentialsProvider()
                {{
                    setCredentials( new AuthScope( proxy.getHost(), proxy.getPort() ),
                            new UsernamePasswordCredentials( proxy.getUsername(),
                                    proxy.getPassword().toCharArray() ) );
                }} );
            }
        } );

but now I've realised we can simply use RepositorySystemSession.getProxySelector() etc. instead (and that also solves password encryption automatically) 😆

[jarmoniuk]

Answer from the current Wagon maintainer is that it is definitely future-proof.
Got an implementation using Wagon ready.

By the way, I'm using RepositorySystemSession.getProxySelector() (and similar methods) instead of querying the settings directly, so that I don't need to bother about possible password encryption.

However, I'm still thinking whether not to simply employ HttpClient 5 instead. Disadvantage of such a solution would be that it would basically boil down to be a yet another reinterpretation of Wagon...

What do you think, @slawekjaranowski @slachiewicz ?

[jarmoniuk]

Rebased and resolved conflicts (a lot of them again). Still weighing in whether I should go with this or simply HttpClient5.

[jarmoniuk]

As you can see -- implementation using Wagon is ready and kicking, but I am still thinking whether not to go with pure HttpClient.

[jarmoniuk]

I've decided that it's not worth it to go with HttpClient5 directly. Too much adapting plus Wagon is already a thin layer around it. Maybe later.

@slawekjaranowski please review
if you decide it's ready, please merge

[slawekjaranowski]

Ok, good enough

[jarmoniuk]

Still working on a version with HttpClient5. But that will come later. Perhaps in the next release.