On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák <ta...@cservenak.net> wrote: > > 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"?
jetty sounds good. But frankly native looks wrong to me (wrong marketing :)) as it is using apache httpclient so this would deserve to be named with what is reality used. reading from the outside using native currently gives a false idea about what is really used. native for me means C code :) native sounds more appropriate for the "jdk native" implementation. maybe the naming could be fixed now with 2.0.0 upgrade. such: - jdk impl -> native - jetty -> jetty - current apache -> htttpciient to have some backward compact maybe auto could use htttpciient just some thought from the peanut gallery. > > T > > On Thu, Oct 12, 2023 at 11:01 PM Olivier Lamy <ol...@apache.org> wrote: > > > On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet <gno...@apache.org> wrote: > > > > > > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák <ta...@cservenak.net> 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: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
