Sorry, sent too fast: Initial test (1st mail) was run on my desktop that uses local MRM/cache, while this run was on my laptop (wifi connected) and now I intentionally used direct access to https://repo.maven.apache.org/maven2/ , no repoman involved.
T On Sat, Feb 19, 2022 at 8:58 PM Tamás Cservenák <[email protected]> wrote: > 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 >>> >>>
