Currently the names are like these: https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L107-L109
So "wagon", "native" (for maven-resolver-transport-http), and "auto" (to apply Resolver built-in auto selection. Hence, I envision "jetty" and "jdk"? T On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy <[email protected]> wrote: > On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet <[email protected]> wrote: > > > > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák <[email protected]> a > > écrit : > > > > > Howdy, > > > > > > As part of the new Resolver major version, one of the goals is to > introduce > > > HTTP/2 capable transports. And as always, naming... > > > > > > Current transport module names (==artifactId) are (already quite long > for > > > my taste): > > > * maven-resolver-transport-classpath (CP transport, is not HTTP, just > FTR) > > > * maven-resolver-transport-file (file transport, is not HTTP, just FTR) > > > * maven-resolver-transport-http (uses Apache HttpClient 4.x, HTTP/1.1 > > > capable) > > > * maven-resolver-transport-wagon (uses Wagon, so is not only HTTP, > HTTP/1.1 > > > capable) > > > > > > > Is wagon something we still want to push forward ? > > > > > > > > > > And now the two new contenders: > > > * Java11+ java.net.http.HttpClient based (HTTP/2 capable) > > > * Java11+ Jetty12 based (HTTP/2 capable) > > > > > > So, the major question is how to name these modules (== artifactId)? > > > > > > * maven-resolver-transport-java11? > > > > * maven-resolver-transport-jetty12? > > > > > > Maybe some form of proto+imple? > > > > > > * maven-resolver-transport-http2-java11 (or shorter > > > maven-resolver-transport-h2-java11) > > > > > > > Http is enough imho. Which version is supported by which implementation > is > > an internal detail. Unless there are HTTP/2 server which does not > support > > HTTP/1.1 in which case it could become relevant. Or any client > supporting > > HTTP/2 and not HTTP/1.1... > > > > > > > > > * maven-resolver-transport-http2-jetty (or shorter > > > maven-resolver-transport-h2-jetty) > > > > > > agree on the no need of Jetty version. > We should be able to use Jetty transport for http1 as well (the Jetty > client can support multiple protocols including http3). > maybe maven-resolver-transport-jetty (as it shouldn't have an http2 > limitation) > > what will be the names to use in poms or cli to activate those > transporters? > Maybe we should keep them short to not have an extra long > configuration esp when using cli. > > > > > I like the longest better because they are more descriptive of what they > > actually are. > > So protocol + client sounds fine. > > > > > > > > > > But there are not ONLY HTTP/2 (they are also HTTP/1.1 capable as well). > > > Also, the Jetty version matters, so once in future there will be > Jetty13 > > > etc... > > > > > > > Do we really care ? We need different providers if they provide different > > things. I don't think jetty 12 provides anything different than jetty > 13. > > In addition, we won't be able to ship both jetty 12 and jetty 13 at the > > same time, so I think we can keep a single one, which means we can drop > the > > version. > > Which version we ship is a separate discussion and it impacts the runtime > > JDK requirements I suppose. > > > > Same for java11, maybe jdk would be better to indicate this is the http > > client from the jdk (if you're using jdk 17, that one will be used, not > the > > one from jdk 11). I do understand it has been introduced in JDK 11, but > > still... > > > > So in short, i'd go for: > > maven-resolver-transport-http-jetty > > maven-resolver-transport-http-jdk > > maven-resolver-transport-http-httpclient > > maven-resolver-transport-file > > maven-resolver-transport-classpath > > > > Cheers > > Guillaume > > > > > > > > > > > > Ideas welcome. > > > > > > Thanks > > > T > > > > > > PS: Given java.net.http.HttpClient based transport will be > dependency-less, > > > it reminds me of good old wagon-http-lightweight, but unlike wagon one > > > (that was quite limited), this will be fully capable transport. > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
