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
