[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651810#comment-17651810
]
ASF GitHub Bot commented on MRESOLVER-308:
------------------------------------------
michael-o commented on PR #231:
URL: https://github.com/apache/maven-resolver/pull/231#issuecomment-1364570706
> Do we really want to keep maintaining that many resolver transport
modules? If there is a clear winner performance wise, why not dropping the
other modules? I fail to see the advantage of providing that many options...
There can never be a clear winner since every client is different and every
environment is different. We just need a small decent set.
> HTTP transport showdown
> -----------------------
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.3
>
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
