Re: Maven Resolver + Wagon
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 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 > 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: >> >> local-repository >> >> >> 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 >> 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 >>> >>>
Re: Maven Resolver + Wagon
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 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: > > local-repository > > > 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 > 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 >> >>
Re: Maven Resolver + Wagon
AFAIK, resolver has API to publish also: it's in o.e.a.deployment https://maven.apache.org/resolver/maven-resolver-api/apidocs/index.html Le jeudi 23 décembre 2021, 17:34:16 CET Arnaud Héritier a écrit : > Sorry I missed this interesting thread. > > I completely agree with your analysis. In 2022 I don’t think anyone consume > its artifacts from another protocol than http(s) or file. It’s probably > another story for the publication and in this area wagon is still making > sense but for the resolver I don’t see any interest to keep it (especially > if it can help to improve the performances and the reduction of layers can > help to simplify and optimize more this part of maven) > > Le jeu. 23 déc. 2021 à 10:56, Tamás Cservenák a > > écrit : > > Ping, no one else has any opinion on this? > > > > T > > > > On Wed, Dec 15, 2021 at 9:26 AM Tamás Cservenák > > > > 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Resolver + Wagon
Sorry I missed this interesting thread. I completely agree with your analysis. In 2022 I don’t think anyone consume its artifacts from another protocol than http(s) or file. It’s probably another story for the publication and in this area wagon is still making sense but for the resolver I don’t see any interest to keep it (especially if it can help to improve the performances and the reduction of layers can help to simplify and optimize more this part of maven) Le jeu. 23 déc. 2021 à 10:56, Tamás Cservenák a écrit : > Ping, no one else has any opinion on this? > > T > > On Wed, Dec 15, 2021 at 9:26 AM Tamás Cservenák > 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 > > > > > -- Arnaud Héritier Twitter/GitHub/... : aheritier
Re: Maven Resolver + Wagon
Ping, no one else has any opinion on this? T On Wed, Dec 15, 2021 at 9:26 AM Tamás Cservenák 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 > >
Re: Maven Resolver + Wagon
I can state an view from not a core developer, but someone who happened to use both, resolver and wagon, in different constellations. The main point for abstraction is to unify implementations and let callers align to it. Given that in the past days wagon was mainly intended for basic operations it reflects this. What we probably miss nowadays is support for combined requests where caller knows that it expects more than one result. I can see two ways for that - either adding a checksum variant for wagon or basic batch api which would let specific providers optimize their parts even more. Question - is it really suitable for initial wagon design and if callers API will not get too complicated? Anyhow, this is just my 0.05€ :-) Best, Łukasz -- Code-House http://code-house.org On 15.12.2021 09:26, Tamás Cservenák 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Resolver + Wagon
Hi Tamas, this is great news! I agree with you that most protocols are either file:// (project-relative repositories) or https:// based nowadays. Thanks! Am Mi., 15. Dez. 2021 um 14:44 Uhr schrieb Guillaume Nodet : > > Such a massive performance improvement is really nice ! I don't know the > whole history behind wagon and other transports so I don't have a strong > opinion about the location of such an improvement , but I definitely > welcome it ! > > Le mer. 15 déc. 2021 à 09:26, Tamás Cservenák a > écrit : > > > 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 > > > > > -- > > Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Resolver + Wagon
Such a massive performance improvement is really nice ! I don't know the whole history behind wagon and other transports so I don't have a strong opinion about the location of such an improvement , but I definitely welcome it ! Le mer. 15 déc. 2021 à 09:26, Tamás Cservenák a écrit : > 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 > -- Guillaume Nodet
Re: Maven Resolver + Wagon
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: local-repository 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 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 > >
