And just add more context about transports:
Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
3.9). Numbers show that "native" is far superior over Wagon (I think we can
all agree on this).
Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
of the best HTTP libraries I used), and this implies we are stuck with
HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
the moment we provided "superior" HTTP transport in Maven, we got stuck at
the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
and async, both require heavy rewrite), switching to it requires _full
rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
protocol. Basically it is like writing resolver transport from scratch.
Hence, I think it is more sane to invest our effort into something more
stable, that at the same time gives us (promises us) future headroom as
well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
HttpClient are such things. There is no need for _full rewrite_ between
major versions.
In the longer term, this will actually lower the needed effort to maintain
these resolver transports, while at the same time prevent us being cornered
again.
On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák <[email protected]>
wrote:
> Howdy,
>
> Re perf (and this was already discussed about a year ago, please do not
> derail discussion): look around
> https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
> there are the numbers. TL;DR: jetty and jdk clients are consistently
> fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as
> well, but with the downside of huge dep trail), while Wagon is consistently
> the slowest. Differences wildly differ but are very notable.
>
> Personally, I am not interested in doing a full rewrite of existing AHC
> transport (as the expected amount of bugs doing this is pretty much on par
> with doing fully new transport from scratch). I'd rather just choose a
> library with a more stable API, like Jetty is. Moreover, forcing "async"
> style in 2023 is something I'd avoid in today's written Java code (esp with
> 21 virtual threads). But sure, if you want to do it, go for it (this work
> would at least move Maven as a project forward, not backward).
>
> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov <[email protected]>
> wrote:
>
>> Regardless of the names, the following questions code to my mind:
>>
>> * Does it make sense to put effort into too many clients?
>> * How many users will actually switch the client? I bet < 10%
>>
>> olegk@ and me assessed many times on JIRA that HTTP/2 will have little
>> performance benefit for our use case of transport. I'd like to see a move
>> to Apache HttpClient 5 Async which does everything, but that is work.
>> Having both AHC async and Jetty HTTP Client is a logical overlap and
>> unnecessary maintenance burden. While I know nothing about the Jetty
>> Client, the AHC (any version) has exceptional logging output down to bytes
>> of streams which helps very often to analyze problem with users.
>>
>> I personally refuse and close out issue on JIRA where the user is not
>> able to present that kind of debugging information. Poking in the dark.
>>
>> M
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
