Simple test (someone could repeat/verify): build maven with reference build (master) and transport-http w/ smart checksums for central build, focusing on "transfer time" (so always empty local repo).
(my) prerequisites: Java11 temurin, Linux, maven 3.8.4 a) build maven master locally (I used 16dd31aba109f5b02269df1ecdebe30f83172f12) = maven-wagon -- this is "reference" b) build locally https://github.com/apache/maven-resolver/pull/140 (it will land as maven-resolver-1.7.3-SNAPSHOT in your local repo) b) build locally https://github.com/apache/maven/pull/635 = maven-http -- this is "contender" For test, I bult maven master (same ref as above) with empty local repo (as it is transfer that is being tested) w/o tests settings.xml: <settings> <localRepository>local-repository</localRepository> </settings> execution: > rm -R local-repository <== MUST, to nuke local repo! > $LOCAL_BUILD/bin/mvn -V -s settings.xml clean package -DfailIfNoTests=false -Dtest=void -Drat.skip=true And repeat that "execution" step for both contender, for "reference" maven and "contender" maven multiple times (don't forget to nuke local repo!). Locally, I have these times (averages): reference - Total time: 01:44 min contender - Total time: 01:07 min Basically, this shaves off 40 seconds out of transport (+ compile, but it is pretty much same for both) times. HTH Tamas On Wed, Dec 15, 2021 at 9:26 AM Tamás Cservenák <[email protected]> wrote: > Howdy, > > I'd like to pitch a topic about maven-resolver and usage of Wagon in it. > As IMHO, Wagon use in maven-resolver is far from optimal (is very > suboptimal). > > Typical example is this PR: > https://github.com/apache/maven-resolver/pull/140 > > This PR _halves HTTP requests made by resolver_ against Maven Central (!) > by utilizing hashes sent by Maven Central in HTTP response header. Hence, > instead of doing GET /a.jar and then GET /a.jar.sha1 it does both at once > with one HTTP request. IMHO, this is huge. But, this works only with > maven-resolver-transport-http that is NOT used with Maven (as it uses > maven-resolver-transport-wagon). Moreover, doing this in Wagon, that is > layer by layer ... of abstractions is just very hard. > > IMHO, back in Maven2 times, when Wagon was conceived, the "transport > agnosticism" and "universal transport" was really a life saver: back then, > people used sticks and duct-tapes to craft "repo solutions", hence access > like SSHFS, Apache httpd + mod_dav and who knows what were common, and > Wagon having supporting all these cases was really a cool thing to have. > > But fast forward 10+ years, there is really no reason to do this today, as > the landscape changed a LOT, there are MRMs on every corner popping up like > mushrooms. I don't really see use of maven-resolver (and maven's use of > maven-resolver) that does not involve HTTP or FILE. > > In short, resolver NOT involving HTTP is something you will VERY RARELY > see. Or in other words, maven-resolver concerning anything NOT HTTP (and > FILE) is just sub optimal. > > So I propose to retarget maven-resolver (and it's use within maven) to use > maven-resolver-transport-http instead of Wagon. Wagon, similarly like > Plexus, is there to stay in Maven, but it's use in maven-resolver is really > really suboptimal. > > > WDYT? > > Tamas > >
