I prefer "jdk" over "jre", as IMHO using the term "jre" would be confusing for users. When Oracle dropped delivering standalone "jre", users stopped using the term as well. Also, a long time ago, there was constant confusion that Maven needed JDK and not JRE to run, as users were by mistake installing JREs and failed to get full Maven functionality... (am talking about 2000s :) ).
IMHO, if we start using the term "jre" today, that might just confuse users... my 5 cents. On Fri, Oct 13, 2023 at 9:50 AM Romain Manni-Bucau <[email protected]> wrote: > s/jdk/jre/ otherwise agree > > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák <[email protected]> a > écrit : > > > 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] > > > > > > > > >
