IMHO in contrary: that comparison is perfectly valid as: - this is what Maven end user gets/experiences - you should know that doing checksum extraction in Wagon today is nearly impossible (we could put another 2 year effort into Wagon, but it would only make it "on par" with native transport, maybe, IMHO, not worth it) - both are still HTTP/1.1 only - IMHO, Wagon benefit (of being protocol agnostic) is also it's biggest downside/hurdle as well: whatever new requirement comes in (like checksum extraction was), it is way simpler solved in implementations like "native" (direct use of client library), instead of gleaning thru layers and layers of abstraction and probably adding new layers to solve it (while those layers are what makes "protocol agnostic" thing possible).
Today: - resolver needs fast, performant and robust transport, dedicated for that purpose only, we don't want a "swiss army knife" that does everything. - The 2000s with "remote repositories made out of sticks" (httpd + mod_dav, etc) are gone, we can all agree that HTTP protocol is the main transport protocol for artifact transport. Hence, ssh, sftp, DAV, and any other exotic thing loses its importance, as today it is only one liner Docker CLI to spin up a fully fledged MRM. As for logging, for JDK I have no idea (and am somewhat aligned with you here, "probably useless"), while for Jetty I am pretty much sure Jetty devs would not hinder, or better, shoot themselves in their foot, by having their supported product produce obfuscated, unusable or scarce debug logs :) So for Jetty and debug, I'd not be worried. On Fri, Oct 13, 2023 at 10:27 AM Michael Osipov <[email protected]> wrote: > You perfectly know that the comparison is not fair because checksum > transport is handled differently. You have to create identical conditions. > > On 2023/10/13 08:11:32 Tamás Cservenák 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] > >
