kwin commented on issue #1608: URL: https://github.com/apache/maven-resolver/issues/1608#issuecomment-3375908320
For the record: https://the-asf.slack.com/archives/C7Q9JB404/p1759231362859829 > Volkan Yazıcı > [Tuesday at 1:22 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759231362859829) > AFAIU, Maven 4, which will baseline Java 17, [will continue using Apache HTTP Client](https://github.com/apache/maven-resolver/blob/mvn4/maven-resolver-transport-http/pom.xml). If so, curious: why not the HttpClient shipped in Java 11? > 96 replies > > > Konrad Windszus > [Tuesday at 1:37 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759232254992979?thread_ts=1759231362.859829&cid=C7Q9JB404) > This is an old/stale branch, please check out master which has [https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-jdk-[…]ava/org/eclipse/aether/transport/jdk/JdkTransporterFactory.java](https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk-11/src/main/java/org/eclipse/aether/transport/jdk/JdkTransporterFactory.java) > [1:37](https://the-asf.slack.com/archives/C7Q9JB404/p1759232265145619?thread_ts=1759231362.859829&cid=C7Q9JB404) > However it is not the default > [1:38](https://the-asf.slack.com/archives/C7Q9JB404/p1759232324062829?thread_ts=1759231362.859829&cid=C7Q9JB404) > for a reasoning please see https://github.com/apache/maven-resolver/commit/2ca95ee0b88fe57c216fa7b3edaad555b80de51e > [1:38](https://the-asf.slack.com/archives/C7Q9JB404/p1759232332094269?thread_ts=1759231362.859829&cid=C7Q9JB404) > Maybe [@cstamas](https://the-asf.slack.com/team/UCAR6KM8S) can share more details > > > cstamas > [Tuesday at 1:40 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759232401091659?thread_ts=1759231362.859829&cid=C7Q9JB404) > all maven 4 versions since some alpha has j.n.h.HttpClient transport > [1:40](https://the-asf.slack.com/archives/C7Q9JB404/p1759232408848709?thread_ts=1759231362.859829&cid=C7Q9JB404) > since Resolver 2.x is used in mvn4 > [1:40](https://the-asf.slack.com/archives/C7Q9JB404/p1759232411926689?thread_ts=1759231362.859829&cid=C7Q9JB404) > but > [1:40](https://the-asf.slack.com/archives/C7Q9JB404/p1759232455082379?thread_ts=1759231362.859829&cid=C7Q9JB404) > as time passed with got a ton of feedback from users about it, and we "demoted it" step by step: for start we had to disable (by def) HTTP/2 as it proved "always break" in some environments > [1:41](https://the-asf.slack.com/archives/C7Q9JB404/p1759232509188759?thread_ts=1759231362.859829&cid=C7Q9JB404) > so latest RC used j.n.h.HttpClient as "simple" HTTP/1.1 client (like the old apache transport), but alas was not "on par", as it does not support some proxy setups apache does > [1:42](https://the-asf.slack.com/archives/C7Q9JB404/p1759232543293419?thread_ts=1759231362.859829&cid=C7Q9JB404) > and finally, upcoming Resolver 2.0.12 we totally demoted it, is not even default transport anymore, due new SSL/TLS issues has > [1:42](https://the-asf.slack.com/archives/C7Q9JB404/p1759232553633979?thread_ts=1759231362.859829&cid=C7Q9JB404) > but user can still opt to use it > [1:42](https://the-asf.slack.com/archives/C7Q9JB404/p1759232575078879?thread_ts=1759231362.859829&cid=C7Q9JB404) > https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Constants.java#L432 > > > Volkan Yazıcı > [Tuesday at 1:44 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759232645332899?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Konrad Windszus](https://the-asf.slack.com/team/UGZHT2R7B) [@cstamas](https://the-asf.slack.com/team/UCAR6KM8S) Would you be okay with if I share this conversation with some OpenJDK members? > > > cstamas > [Tuesday at 1:44 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759232654154879?thread_ts=1759231362.859829&cid=C7Q9JB404) > sure > [1:44](https://the-asf.slack.com/archives/C7Q9JB404/p1759232678253819?thread_ts=1759231362.859829&cid=C7Q9JB404) > there are even JDK jiras for these > [1:44](https://the-asf.slack.com/archives/C7Q9JB404/p1759232683847449?thread_ts=1759231362.859829&cid=C7Q9JB404) > so they should be aware of it > > > Volkan Yazıcı > [Tuesday at 1:45 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759232723795069?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@cstamas](https://the-asf.slack.com/team/UCAR6KM8S) Would you mind pointing me to the > "new SSL/TLS issues", > "it proved 'always break' in some environments", and > "JDK jiras", please? > > > cstamas > [Tuesday at 1:45 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759232737997189?thread_ts=1759231362.859829&cid=C7Q9JB404) > https://issues.apache.org/jira/browse/MNG-8145 > [1:45](https://the-asf.slack.com/archives/C7Q9JB404/p1759232742865299?thread_ts=1759231362.859829&cid=C7Q9JB404) > the well known GOAWAY issue > [1:45](https://the-asf.slack.com/archives/C7Q9JB404/p1759232746738859?thread_ts=1759231362.859829&cid=C7Q9JB404) > cannot be handled > [1:46](https://the-asf.slack.com/archives/C7Q9JB404/p1759232775442669?thread_ts=1759231362.859829&cid=C7Q9JB404) > in these evnironments it is INEVITABLE to get GOAWAY, but httpClient does not expose ANY MEANS to handle it > [1:46](https://the-asf.slack.com/archives/C7Q9JB404/p1759232795661279?thread_ts=1759231362.859829&cid=C7Q9JB404) > (aside of some exception message contains assertion or alike) > [1:51](https://the-asf.slack.com/archives/C7Q9JB404/p1759233095424849?thread_ts=1759231362.859829&cid=C7Q9JB404) > fixed only in latest Javas https://bugs.openjdk.org/browse/JDK-8335181 for example, and this assume that all maven users update JDKs to latest, which is not always the case, and we can get flooded with issues we cannot handle, etc > [1:55](https://the-asf.slack.com/archives/C7Q9JB404/p1759233316113869?thread_ts=1759231362.859829&cid=C7Q9JB404) > btw, I agree that having new Maven 4 with ancient (default) transport using ASF HttpClient 4.x is far, very far from ideal, but the Java HttpClient proved too limited, while for other transport like new ASF HttpClient 5.x transport it seems there is no interest https://github.com/apache/maven-resolver/pull/742 nor in maven project nor in httpcomponents project (edited) > [1:56](https://the-asf.slack.com/archives/C7Q9JB404/p1759233364283019?thread_ts=1759231362.859829&cid=C7Q9JB404) > I alone cannot get to it, maybe later > > > cstamas > [Tuesday at 2:03 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759233820255579?thread_ts=1759231362.859829&cid=C7Q9JB404) > oh, also issues like these https://bugs.openjdk.org/browse/JDK-8283544 prevents transport to use services like jitpack https://github.com/jitpack/jitpack.io/issues/7186 > [2:03](https://the-asf.slack.com/archives/C7Q9JB404/p1759233828505119?thread_ts=1759231362.859829&cid=C7Q9JB404) > so many little annoying but not solvable issues > > > cstamas > [Tuesday at 2:12 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759234337941389?thread_ts=1759231362.859829&cid=C7Q9JB404) > not solvable == as it is not a library but part of JDK :slightly_smiling_face: so we cannot just "up the version" and release, but we need to talk users into upgrading their JDK > [2:12](https://the-asf.slack.com/archives/C7Q9JB404/p1759234359648809?thread_ts=1759231362.859829&cid=C7Q9JB404) > and that is many times not so simple > > > cstamas > [Tuesday at 2:19 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759234747007889?thread_ts=1759231362.859829&cid=C7Q9JB404) > TBH, for simple cases (like for example for me, simple home network, nothing fancy, going directly for Central) JDK HttpClient w/ HTTP/2 was working very well and was fast, on the builds I usually build, but on larger build, like of those of quarkus or camel, it knew to "suddenly die" and break the build > [2:21](https://the-asf.slack.com/archives/C7Q9JB404/p1759234888855909?thread_ts=1759231362.859829&cid=C7Q9JB404) > so I think JDK HttpClient may be considered as Wagon HTTP Lightweight was, good to "bootstrap" things, but.... > [2:22](https://the-asf.slack.com/archives/C7Q9JB404/p1759234956906259?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Romain](https://the-asf.slack.com/team/U9FK7J7BK) ^ something to add? He was one of the users yelling when I "demoted" it, he also says "works for him" but at the cost of some "tuning" (JDK props) > [2:25](https://the-asf.slack.com/archives/C7Q9JB404/p1759235124513379?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Guillaume Nodet](https://the-asf.slack.com/team/UFJTM3PBL) ^ > > > Romain > [Tuesday at 3:44 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759239879790769?thread_ts=1759231362.859829&cid=C7Q9JB404) > well for me it always worked without tuning, the tuning mention was using the JRE HttpClient in some apps not maven - but guess it converges at some point :wink: > but I got way more issues with apache http client lately > while the transport uses dep mechanism and can be set globally in the settings or ~/.mavenrc I guess it is ok :angel: > > > Volkan Yazıcı > [Tuesday at 8:25 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759256728572239?thread_ts=1759231362.859829&cid=C7Q9JB404) > Using the cited issues, I've compiled the following: > Incorrect handling of GOAWAY – [MNG-8145](https://issues.apache.org/jira/browse/MNG-8145) [JDK-8335181](https://bugs.openjdk.org/browse/JDK-8335181) (delivered in Java 24, ported to 17 & 21) > GET method adds Content-Length: 0 header, rendering services like JitPack unusable – [jitpack/jitpack.io#7186](https://github.com/jitpack/jitpack.io/issues/7186) [JDK-8283544](https://bugs.openjdk.org/browse/JDK-8283544) (delivered in Java 19) > I see JDK-8283544 is marked as a 11 & 17 backport candidate, though not processed yet. > If we would also get JDK-8283544 into 17u, would you consider introducing JDK's HttpClient as the default? > > > cstamas > [Tuesday at 8:26 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759256788753639?thread_ts=1759231362.859829&cid=C7Q9JB404) > Yes, I'd love to (and enable HTTP/2 on it), as I said, it is very good in these scenarios > [8:27](https://the-asf.slack.com/archives/C7Q9JB404/p1759256864818209?thread_ts=1759231362.859829&cid=C7Q9JB404) > there is a third issue, something regarding TLS/SSL, but to be frank, I just "heard" about that issue (and our CI was failing due SSL/TLS handshake) and it was just another reason added, but maybe not recorded in form of issue/JIRA > > > Volkan Yazıcı > [Tuesday at 8:41 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759257699226609?thread_ts=1759231362.859829&cid=C7Q9JB404) > I'd really appreciate it if you can provide more details about the TLS/SSL issue. I'd gladly help to get it prioritized at the OpenJDK side. > > > cstamas > [Tuesday at 8:45 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759257951832319?thread_ts=1759231362.859829&cid=C7Q9JB404) > I cannot sadly, it just happens on CI, on GH action to be more precise, for example here https://github.com/apache/maven/actions/runs/17913416241/job/50929944116 > [8:46](https://the-asf.slack.com/archives/C7Q9JB404/p1759257977574209?thread_ts=1759231362.859829&cid=C7Q9JB404) > but, due resolver codebase, you cannot see HttpClient in stack traces, only the message coming from it > [8:46](https://the-asf.slack.com/archives/C7Q9JB404/p1759257992087579?thread_ts=1759231362.859829&cid=C7Q9JB404) > Caused by: org.apache.maven.api.services.model.ModelResolverException: The following artifacts could not be resolved: eu.maveniverse.maven.mimir:mimir:pom:0.7.8 (absent): Could not transfer artifact eu.maveniverse.maven.mimir:mimir:pom:0.7.8 from/to central (https://repo.maven.apache.org/maven2): Remote host terminated the handshake (remote repositories: central (https://repo.maven.apache.org/maven2, default, releases)) > at org.apache.maven.impl.resolver.DefaultModelResolver.doResolveModel(DefaultModelResolver.java:160) > at org.apache.maven.impl.resolver.DefaultModelResolver.lambda$resolveModel$0(DefaultModelResolver.java:113) > :eyes: > 1 > > > > Romain > [Tuesday at 8:54 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759258495809879?thread_ts=1759231362.859829&cid=C7Q9JB404) > do you set tls version as system prop? ( > https.protocols > ) (edited) > > > Konrad Windszus > [Tuesday at 9:51 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759261898126359?thread_ts=1759231362.859829&cid=C7Q9JB404) > I think for https://bugs.openjdk.org/browse/JDK-8283544 there was a workaround to use another constructor used in our code, right [@cstamas](https://the-asf.slack.com/team/UCAR6KM8S)? > > > cstamas > [Tuesday at 10:03 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759262583802869?thread_ts=1759231362.859829&cid=C7Q9JB404) > https://github.com/apache/maven-resolver/commit/fac15698f716d0e076459933b36c0b97bf183019 > [10:03](https://the-asf.slack.com/archives/C7Q9JB404/p1759262594852829?thread_ts=1759231362.859829&cid=C7Q9JB404) > but there was this as well https://github.com/apache/maven-resolver/pull/1509/files > [10:03](https://the-asf.slack.com/archives/C7Q9JB404/p1759262617218409?thread_ts=1759231362.859829&cid=C7Q9JB404) > and this [https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-jdk-[…]/main/java/org/eclipse/aether/transport/jdk/JdkTransporter.java](https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk-11/src/main/java/org/eclipse/aether/transport/jdk/JdkTransporter.java#L203-L212) > [10:05](https://the-asf.slack.com/archives/C7Q9JB404/p1759262700355169?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Romain](https://the-asf.slack.com/team/U9FK7J7BK) no prop set, all is "vanilla" on GH CI like you have locally > [10:06](https://the-asf.slack.com/archives/C7Q9JB404/p1759262800641619?thread_ts=1759231362.859829&cid=C7Q9JB404) > the TLS issues are intermittent and that is why we never could reproduce them (or when happen, we have no any debug log, as that would clog logging) > > > Romain > [Tuesday at 10:13 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759263191318919?thread_ts=1759231362.859829&cid=C7Q9JB404) > can be worth trying, there are 4-5 props more or less official/hidden which help > [10:13](https://the-asf.slack.com/archives/C7Q9JB404/p1759263204205679?thread_ts=1759231362.859829&cid=C7Q9JB404) > sadly some must be set on the jvm otherwise it comes likely too late > > > Matthias Bünger > [Wednesday at 2:27 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759321647897209?thread_ts=1759231362.859829&cid=C7Q9JB404) > We have the same thing at my work. We would like to use the JDK one, but that does not support custom verifier > > > Volkan Yazıcı > [Wednesday at 2:29 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759321757064379?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Matthias Bünger](https://the-asf.slack.com/team/U08BS468G6S) Mind elaborating on what you mean with "[Java HttpClient] does not support custom verifier", please? > > > Matthias Bünger > [Wednesday at 2:32 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759321942526079?thread_ts=1759231362.859829&cid=C7Q9JB404) > We need to disable hostname-verifier on a client base (it‘s only possible globally via system property). That‘s why we also use the Apache one > > > Romain > [Wednesday at 2:38 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759322311343329?thread_ts=1759231362.859829&cid=C7Q9JB404) > We would like to use the JDK one, but that does not support custom verifier > I'm pretty sure this is not true but the API changed IIRC and is lower level (edited) > > > cstamas > [Wednesday at 2:39 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759322389020659?thread_ts=1759231362.859829&cid=C7Q9JB404) > is global only https://bugs.openjdk.org/browse/JDK-8213309 > > > Romain > [Wednesday at 2:43 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759322601949309?thread_ts=1759231362.859829&cid=C7Q9JB404) > the system prop, not the impl > [2:44](https://the-asf.slack.com/archives/C7Q9JB404/p1759322661249619?thread_ts=1759231362.859829&cid=C7Q9JB404) > in your ssl context i think you can set sslParameters.setEndpointIdentificationAlgorithm to disable it > [2:44](https://the-asf.slack.com/archives/C7Q9JB404/p1759322693419559?thread_ts=1759231362.859829&cid=C7Q9JB404) > (makes almost 2 years I didn't do it again but there is something like that to do it) > > > Volkan Yazıcı > [Wednesday at 3:03 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759323835500159?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Matthias Bünger](https://the-asf.slack.com/team/U08BS468G6S) [@Romain](https://the-asf.slack.com/team/U9FK7J7BK) [@cstamas](https://the-asf.slack.com/team/UCAR6KM8S) Thanks for the valuable feedback! I've communicated these to the net-dev crew. If you have any further remarks, pain (or nice?) points to share, I'd be more than happy to hear. > :beers: > 2 > > > > Christoph Läubrich > [Friday at 12:43 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759488181193269?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Volkan Yazıcı](https://the-asf.slack.com/team/U015FDWQTBJ) Tycho suffers from the same problems (mainly HTTP GOAWAY) what is a real pita ...). > In general I think we also noticed missing NTLM support and proxy auth let me check... > [12:43](https://the-asf.slack.com/archives/C7Q9JB404/p1759488203989559?thread_ts=1759231362.859829&cid=C7Q9JB404) > Beside that I found this one quite blocking wen it comes to switching protocols: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8361305 > bugs.java.com > [Bug ID: JDK-8361305 WebSocket.Builder should support HTTP Upgrades to a Websocket Connection](https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8361305) > Component: core-libs | Sub-Component: [java.net](http://java.net/) > [12:44](https://the-asf.slack.com/archives/C7Q9JB404/p1759488255136679?thread_ts=1759231362.859829&cid=C7Q9JB404) > Found it: > - https://github.com/eclipse-ecf/ecf/issues/76 > [12:46](https://the-asf.slack.com/archives/C7Q9JB404/p1759488416807409?thread_ts=1759231362.859829&cid=C7Q9JB404) > Theres also this one https://stackoverflow.com/questions/69320901/jdk-http-client-ntlm > Stack OverflowStack Overflow > [jdk http client ntlm](https://stackoverflow.com/questions/69320901/jdk-http-client-ntlm) > I am not by far an expert in different protocols over http, but I can do this with curl to one of the APIs at my workplace: > curl --http1.1 --ntlm -u 'user:pass' 'MY_URL' > This works just fine. But > > > > > > > cstamas > [Friday at 12:47 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759488473586599?thread_ts=1759231362.859829&cid=C7Q9JB404) > isn't NTLM being dropped by MS as well? Also apache client5 dropped support for it AFAIK (edited) > > > Christoph Läubrich > [Friday at 12:49 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759488541477579?thread_ts=1759231362.859829&cid=C7Q9JB404) > I jsut knwo some users (mostly bigger companiees) complain when NTLM/Kerberos whatever they use :smile: > [12:49](https://the-asf.slack.com/archives/C7Q9JB404/p1759488563611279?thread_ts=1759231362.859829&cid=C7Q9JB404) > I personally have no use for it :sweat_smile: > [12:50](https://the-asf.slack.com/archives/C7Q9JB404/p1759488621977019?thread_ts=1759231362.859829&cid=C7Q9JB404) > But ist often the legacy that hinders adoption of new technologies. > [12:51](https://the-asf.slack.com/archives/C7Q9JB404/p1759488703274439?thread_ts=1759231362.859829&cid=C7Q9JB404) > Also at some kind it seems HttpUrlConnection has support for it so I think its not smth completeley new to the JDK > > > cstamas > [Friday at 12:52 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759488722796169?thread_ts=1759231362.859829&cid=C7Q9JB404) > that class is java 1.0. no? :smile: > > > Christoph Läubrich > [Friday at 12:52 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759488738209499?thread_ts=1759231362.859829&cid=C7Q9JB404) > :man-shrugging: > [12:53](https://the-asf.slack.com/archives/C7Q9JB404/p1759488823019839?thread_ts=1759231362.859829&cid=C7Q9JB404) > So as long as pache-http offers "more" support its hard to argue to use the builtin if it lacks features even if they are only used in a small cases > > > cstamas > [Friday at 12:54 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759488860649579?thread_ts=1759231362.859829&cid=C7Q9JB404) > JDK client is not by any means "apache client replacement" :smile: (IMHO at least) (edited) > > > Christoph Läubrich > [Friday at 12:59 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759489141804279?thread_ts=1759231362.859829&cid=C7Q9JB404) > Well question was how to make it the default, what makes it a replacement somehow :wink: > > > Romain > [Friday at 3:39 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759498758518839?thread_ts=1759231362.859829&cid=C7Q9JB404) > well thing is both have drawbacks and will bother users, jre one is built in as only advantage but it is a big one so 49-51 in favor of jre one for me > > > Volkan Yazıcı > [Friday at 3:49 PM](https://the-asf.slack.com/archives/C7Q9JB404/p1759499377314339?thread_ts=1759231362.859829&cid=C7Q9JB404) > [@Christoph Läubrich](https://the-asf.slack.com/team/U04C7DDCNQN) Thanks so much! I've shared all these remarks with the HttpClient maintainers. Much appreciated! :bow: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
