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] > > > > >
