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 <[email protected]> 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 <[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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
