[ 
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652301#comment-17652301
 ] 

ASF GitHub Bot commented on MRESOLVER-308:
------------------------------------------

cstamas commented on PR #231:
URL: https://github.com/apache/maven-resolver/pull/231#issuecomment-1366133370

   Just to clear up: the fact we have here 5 (7 to be exact) transports, that 
does not mean we need to deliver all these with Maven. Or in other words, 
transport-http, transport-file and transport-classpath was present since day 0 
(of resolver existence), but _no Maven included it so far_. Maven 3.9/4.0 will 
be the first that will include transport-http.
   
   There are 4 transports already (file, http, wagon, classpath), and this PR 
adds 3 new modules. But, the thing is, these are all for HTTP protocol (when 
protocol of remote repository is HTTP/HTTPS). These are the "old" ones:
   * wagon
   * http (aka "native")
   
   While these are new:
   * java11
   * jetty
   * okhttp
   
   New ones are all HTTP/2 capable. Personally, from new ones, I'd remove 
okhttp (cons: pulls in kotlin runtime and is slowest H2 client). Java11 and 
Jetty were really close to each other.
   
   In short: the fact a transport is present here, does not mean _we must ship 
it_, as the case of transport-classpath and transport-http shows (they were 
present since day 0 of resolver, but never shipped).




> 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)

Reply via email to