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
