On Fri, 13 Oct 2023 at 19:12, Tamás Cservenák <ta...@cservenak.net> wrote: > > 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 :) ).
yup jdk makes more sense to me as well (as anyway Maven users have a jdk as they are compiling sources. Regarding logs with Jetty, no worries you can even get more than what you really need :) Jetty have a nice easy to use async API (it's the natural usage of it) http2 sounds a good nice to have (even if it doesn't improve so much performance at least this can reduce load on server by reducing concurrent connection number) http3 not sure it;s something to focus on at least now... > > 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 <rmannibu...@gmail.com> > wrote: > > > s/jdk/jre/ otherwise agree > > > > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák <ta...@cservenak.net> 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 <m...@laeubi-soft.de> > > > 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 <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 > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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
