Howdy, Update PR https://github.com/apache/maven/pull/635 Now transport-wagon and transport-http COEXISTS and are selectable (and no more shaded httpClient either). By default (this is from start like this) transport-http is preferred, so is picked by default. But, using resolver "tricks" you can still switch between transports.
So, I just repeated the experiment: 1. built maven-resolver 1.8.0-SNAPSHOT (master) 2. built maven PR 635 As test, I checked out maven master (to not depend on 1.8.0-SNAPSHOT resolver), and built it twice always with empty local repo: 1st with transport-http: CMD: ~/bin/apache-maven-4.0.0-alpha-1-SNAPSHOT/bin/mvn -Dmaven.repo.local=local-repo clean install -Dtest=void -Dit.test=void -DfailIfNoTests=false -Drat.skip=true USES: transport-http Total time: 01:39 min CMD: ~/bin/apache-maven-4.0.0-alpha-1-SNAPSHOT/bin/mvn -Dmaven.repo.local=local-repo clean install -Dtest=void -Dit.test=void -DfailIfNoTests=false -Drat.skip=true -Daether.priority.WagonTransporterFactory=100 USES: transport-wagon Total time: 02:27 min Have fun T On Wed, Dec 15, 2021 at 12:20 PM Tamás Cservenák <[email protected]> wrote: > 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 >> >>
