Howdy, Maven Central supports HTTP/2 for quite some time. Google Mirror of Maven Central in the EU has supported HTTP/3 since a while ago.
And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for example in the sense of used ports, that may be important on farm-sized CI, also there is noticeable perf improvement as well), the real boost will be probably HTTP/3. Sadly, a year or more ago, when I did perf testing, Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today. I agree also: - jdk/jre client is clearly way to go forward (and is even dependency-less, so would make Maven distro even lighter, but unlike wagon-http-lightweight, is fully featured) - jetty client is "way forward" for those who may want early adoption on things like HTTP/3 etc (at the cost of more deps) On Fri, Oct 13, 2023 at 10:50 AM Romain Manni-Bucau <[email protected]> wrote: > Less is better in terms of stack so jre client is the way forward for me, > it is fast, reliable and keeps getting enhancements. > > On http2/3 I dont see it very relevant cause it still gets a lot of issues > and should be blacklisted for a while until serious mitigations are set up > on servers. > > In terms of style, virtual threads are just a default async style which is > not mainstream and will not for years. It also foes not prevent locking, in > particular with our current codebase so a full rewrite is relevant if there > is any will and if not becoming lighter is what is the most relevant. > > All that to say that staying on jre client, keeping an abstractio is what > I see as relevant. > Other impl can be extensions in an extra repo but sound additional > maintenance without end user gain from my window. > > > Le ven. 13 oct. 2023 à 10:30, Michael Osipov <[email protected]> a > écrit : > > > I agree that this is a full rewrite, sadly. > > > > Have you evaluated what degree of logging both JEtty Client and the JDK > > Client offer? I consider the JDK client likely as useless in this regard. > > Don't know about Jetty. At least AHC saved me a lot of trouble... > > > > On 2023/10/13 08:23:33 Tamás Cservenák wrote: > > > 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] > > > >> > > > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
