Howdy, I am leaning toward: maven-resolver-transport-jetty (name "jetty") <- NEW maven-resolver-transport-jdk (name "jdk") <- NEW maven-resolver-transport-http (name "http", CLI name "native") w/o module rename maven-resolver-transport-file maven-resolver-transport-classpath
As I agree with above mentioned reasons (jetty version, etc) but I would not go for existing -http module rename, as we promised "simple upgrade" for Resolver 1.x users... In short, code that works with 1.x resolver should still work unchanged with 2.x resolver (if it does not use deprecated stuff that is about to be dropped). The "name" is actually Sisu component name (ATNamed), but is also a short name used on Maven CLI to select transport. Again, "native" is cuckoo egg here, rest is nicely aligned. Maven4 could advertise existing maven-resolver-transport-http as CLI name "something else" instead of "native" (but offer some transition period supporting "native" CLI name as well)... Re CLI name, we could offer indirection, like following "meta names" that may mean one or more actual transport implementations (am talking about CLI param maven.resolver.transport): - "http": means jdk, jetty, http - "http1": means jdk, jetty, http - "http2": means jdk, jetty - "http3": means jetty etc Hence, I'd: - not rename (change artifactId) the existing Apache HttpClient 4.x backed transport module (would break code using 1.x) - name new modules simply -jetty and -jdk (with corresponding "names" as well, have those aligned) - transition badly named "native" on CLI into something else (but what?) On Fri, Oct 13, 2023 at 9:08 AM Christoph Läubrich <[email protected]> wrote: > maybe better > > - jdk impl -> jdk > - jetty -> jetty > - current apache -> apache > > Am 13.10.23 um 02:30 schrieb Olivier Lamy: > > On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák <[email protected]> > 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 <[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] > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
