Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
On Sat, 14 Oct 2023 at 10:51, Tamás Cservenák wrote: > > Howdy, > > ok, so I think agreed on the name (and artifactId) of the two new module: > * maven-resolver-transport-jdk (uses Java11+ java.net.http.HttpClient) > * maven-resolver-transport-jetty (uses Jetty HttpClient, probably 12.x) no need real of Jety 12. This will not make a real difference except to make Java 17 mandatory. > > and the existing ones are: > > * 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) > > Cannot rename the misleading "-http" one, as that would cause disruption > with existing code, we have to live with it for now (to be renamed in > resolver 3.0 or so) :( > Aren't we already talking now about a jump from 1.9.x to 2.x :) relocation if so desperate? > As for CLI names and Maven4 inclusion in distro (these are Maven4 changes, > not resolver changes), I'd propose: > * "jdk" included in distro > * "jetty" not included in distro (users can add it via .mvn/extensions.xml) > * "apache" (and deprecated CLI synonym "native") included in distro > * maven-resolver-transport-wagon is to be dropped from Maven4 (not shipped > by default, users can add it as core extension and make it work via > standard resolver priority mechanism. Wagon itself IS present in the Maven4 > core, as it is required for Maven3 compatibility provided by Maven4). > > Transport priorities (how Resolver selects transport if multiple one exists > for same protocol): > wagon = -1.0f (unchanged, same as today) > https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporterFactory.java#L47 > apache = 5.0f (unchanged, same as today) > https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporterFactory.java#L51 > jdk = 10.0f (proposed, to prevail "apache" transport, both will be present > in distro) > jetty = 15.0f (proposed, to prevail "jdk" transport, if present) > > Note re priorities: Resolver "prioritized components" mechanism was present > since day 0 of resolver, and its purpose was to select a given > implementation if multiple ones are suited (like in our case, > TransportFactory for HTTP URL). Before Maven 3.9, wagon transport was the > ONLY HTTP capable transport present on classpath, so selection was trivial. > In Maven 3.9 both wagon and apache transports were present in distro, and > apache "prevails" by default (due default priorities, while CLI switches > tweak priorities). To not introduce changes in this area, the idea is to > position jdk transport above apache (hence priority 10, to prevail apache, > become default), while jetty priority of 15 (it is not present in distro by > default) is simply to make it "if present, it prevails". So to say, to > simplify users' lives who took effort to set it as a core extension (and to > not have to tweak more than that). +1 lgtm > > Note1: Essentially we can play "same game" as we did with Maven 3.9: we > will switch default transport AGAIN IF user uses Java11+ (but this time > from apache/native to jdk), providing fallback for users hitting a blocker > bug in the form of `-Dmaven.resolver.transport=apache`, and for those still > relying on Wagon (ie. using legacy config), they would need two steps a) > make wagon transport be in .mvn/extensions.xml and b) use > `-Dmaven.resolver.transport=wagon`. I believe this is acceptable, while we > are in "alpha" with Maven 4. Of course, this last paragraph is just a > proposal, does not have to happen (we can make it in 4.1 or alike). > Note2: the "...if user uses Java11+" is nicely handled by Sisu. If Maven4 > remains Java8 bytecode level, and the user uses Java8 to run Maven4, Sisu > will silently omit jdk transport (as Java8 will be unable to load the > Java11 bytecode). > > If anyone objects, please yell here. Otherwise will continue along > these lines. > > Thanks > T > > > > On Fri, Oct 13, 2023 at 1:12 PM Romain Manni-Bucau > wrote: > > > Le ven. 13 oct. 2023 à 11:07, Tamás Cservenák a > > écrit : > > > > > Howdy, > > > > > > Maven Central supports HTTP/2 for quite some time. > > > Google Mirror of Maven Central in the EU has supported HTTP/3 since a > > while > > > ago. > > > > > > And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for > > > example in the sense of used ports, that may be important on farm-sized > > CI, > > > also there is noticeable perf improvement as well), the real boost will > > be > > > probably HTTP/3. Sadly, a year or more ago, when I did perf testing, > > > Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today. > > > > > > > Until you protect servers against ddos, so we shouldnt benefit from there > > and boost is
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
> Cannot rename the misleading "-http" one, as that would cause > disruption with existing code, we have to live with it for now Isn't this something maven has relocations[1] for? [1] https://maven.apache.org/guides/mini/guide-relocation.html Am 14.10.23 um 02:51 schrieb Tamás Cservenák: Howdy, ok, so I think agreed on the name (and artifactId) of the two new module: * maven-resolver-transport-jdk (uses Java11+ java.net.http.HttpClient) * maven-resolver-transport-jetty (uses Jetty HttpClient, probably 12.x) and the existing ones are: * 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) Cannot rename the misleading "-http" one, as that would cause disruption with existing code, we have to live with it for now (to be renamed in resolver 3.0 or so) :( As for CLI names and Maven4 inclusion in distro (these are Maven4 changes, not resolver changes), I'd propose: * "jdk" included in distro * "jetty" not included in distro (users can add it via .mvn/extensions.xml) * "apache" (and deprecated CLI synonym "native") included in distro * maven-resolver-transport-wagon is to be dropped from Maven4 (not shipped by default, users can add it as core extension and make it work via standard resolver priority mechanism. Wagon itself IS present in the Maven4 core, as it is required for Maven3 compatibility provided by Maven4). Transport priorities (how Resolver selects transport if multiple one exists for same protocol): wagon = -1.0f (unchanged, same as today) https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporterFactory.java#L47 apache = 5.0f (unchanged, same as today) https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporterFactory.java#L51 jdk = 10.0f (proposed, to prevail "apache" transport, both will be present in distro) jetty = 15.0f (proposed, to prevail "jdk" transport, if present) Note re priorities: Resolver "prioritized components" mechanism was present since day 0 of resolver, and its purpose was to select a given implementation if multiple ones are suited (like in our case, TransportFactory for HTTP URL). Before Maven 3.9, wagon transport was the ONLY HTTP capable transport present on classpath, so selection was trivial. In Maven 3.9 both wagon and apache transports were present in distro, and apache "prevails" by default (due default priorities, while CLI switches tweak priorities). To not introduce changes in this area, the idea is to position jdk transport above apache (hence priority 10, to prevail apache, become default), while jetty priority of 15 (it is not present in distro by default) is simply to make it "if present, it prevails". So to say, to simplify users' lives who took effort to set it as a core extension (and to not have to tweak more than that). Note1: Essentially we can play "same game" as we did with Maven 3.9: we will switch default transport AGAIN IF user uses Java11+ (but this time from apache/native to jdk), providing fallback for users hitting a blocker bug in the form of `-Dmaven.resolver.transport=apache`, and for those still relying on Wagon (ie. using legacy config), they would need two steps a) make wagon transport be in .mvn/extensions.xml and b) use `-Dmaven.resolver.transport=wagon`. I believe this is acceptable, while we are in "alpha" with Maven 4. Of course, this last paragraph is just a proposal, does not have to happen (we can make it in 4.1 or alike). Note2: the "...if user uses Java11+" is nicely handled by Sisu. If Maven4 remains Java8 bytecode level, and the user uses Java8 to run Maven4, Sisu will silently omit jdk transport (as Java8 will be unable to load the Java11 bytecode). If anyone objects, please yell here. Otherwise will continue along these lines. Thanks T On Fri, Oct 13, 2023 at 1:12 PM Romain Manni-Bucau wrote: Le ven. 13 oct. 2023 à 11:07, Tamás Cservenák a écrit : Howdy, Maven Central supports HTTP/2 for quite some time. Google Mirror of Maven Central in the EU has supported HTTP/3 since a while ago. And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for example in the sense of used ports, that may be important on farm-sized CI, also there is noticeable perf improvement as well), the real boost will be probably HTTP/3. Sadly, a year or more ago, when I did perf testing, Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today. Until you protect servers against ddos, so we shouldnt benefit from there and boost is not really in these protocol but more in nio usage where you get way faster than current sync whetever protocol you use. I agree also: - jdk/jre client is clearly way to go forward (and is even
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Howdy, ok, so I think agreed on the name (and artifactId) of the two new module: * maven-resolver-transport-jdk (uses Java11+ java.net.http.HttpClient) * maven-resolver-transport-jetty (uses Jetty HttpClient, probably 12.x) and the existing ones are: * 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) Cannot rename the misleading "-http" one, as that would cause disruption with existing code, we have to live with it for now (to be renamed in resolver 3.0 or so) :( As for CLI names and Maven4 inclusion in distro (these are Maven4 changes, not resolver changes), I'd propose: * "jdk" included in distro * "jetty" not included in distro (users can add it via .mvn/extensions.xml) * "apache" (and deprecated CLI synonym "native") included in distro * maven-resolver-transport-wagon is to be dropped from Maven4 (not shipped by default, users can add it as core extension and make it work via standard resolver priority mechanism. Wagon itself IS present in the Maven4 core, as it is required for Maven3 compatibility provided by Maven4). Transport priorities (how Resolver selects transport if multiple one exists for same protocol): wagon = -1.0f (unchanged, same as today) https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporterFactory.java#L47 apache = 5.0f (unchanged, same as today) https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.16/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporterFactory.java#L51 jdk = 10.0f (proposed, to prevail "apache" transport, both will be present in distro) jetty = 15.0f (proposed, to prevail "jdk" transport, if present) Note re priorities: Resolver "prioritized components" mechanism was present since day 0 of resolver, and its purpose was to select a given implementation if multiple ones are suited (like in our case, TransportFactory for HTTP URL). Before Maven 3.9, wagon transport was the ONLY HTTP capable transport present on classpath, so selection was trivial. In Maven 3.9 both wagon and apache transports were present in distro, and apache "prevails" by default (due default priorities, while CLI switches tweak priorities). To not introduce changes in this area, the idea is to position jdk transport above apache (hence priority 10, to prevail apache, become default), while jetty priority of 15 (it is not present in distro by default) is simply to make it "if present, it prevails". So to say, to simplify users' lives who took effort to set it as a core extension (and to not have to tweak more than that). Note1: Essentially we can play "same game" as we did with Maven 3.9: we will switch default transport AGAIN IF user uses Java11+ (but this time from apache/native to jdk), providing fallback for users hitting a blocker bug in the form of `-Dmaven.resolver.transport=apache`, and for those still relying on Wagon (ie. using legacy config), they would need two steps a) make wagon transport be in .mvn/extensions.xml and b) use `-Dmaven.resolver.transport=wagon`. I believe this is acceptable, while we are in "alpha" with Maven 4. Of course, this last paragraph is just a proposal, does not have to happen (we can make it in 4.1 or alike). Note2: the "...if user uses Java11+" is nicely handled by Sisu. If Maven4 remains Java8 bytecode level, and the user uses Java8 to run Maven4, Sisu will silently omit jdk transport (as Java8 will be unable to load the Java11 bytecode). If anyone objects, please yell here. Otherwise will continue along these lines. Thanks T On Fri, Oct 13, 2023 at 1:12 PM Romain Manni-Bucau wrote: > Le ven. 13 oct. 2023 à 11:07, Tamás Cservenák a > écrit : > > > Howdy, > > > > Maven Central supports HTTP/2 for quite some time. > > Google Mirror of Maven Central in the EU has supported HTTP/3 since a > while > > ago. > > > > And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for > > example in the sense of used ports, that may be important on farm-sized > CI, > > also there is noticeable perf improvement as well), the real boost will > be > > probably HTTP/3. Sadly, a year or more ago, when I did perf testing, > > Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today. > > > > Until you protect servers against ddos, so we shouldnt benefit from there > and boost is not really in these protocol but more in nio usage where you > get way faster than current sync whetever protocol you use. > > > > > I agree also: > > - jdk/jre client is clearly way to go forward (and is even > dependency-less, > > so would make Maven distro even lighter, but unlike > wagon-http-lightweight, > > is fully featured) > > - jetty client is "way forward" for those who may want early adoption on > > things like HTTP/3 etc
[VOTE] Release Maven Site Plugin version 4.0.0-M11
Hi, IMPORTANT: This require the following staging repositories: * Doxia 2.0.0-M8 * Maven Reporting API 4.0.0-M8 * Doxia Sitetools 2.0.0-M13 * Maven Reporting Impl 4.0.0-M11 * Maven Reporting Exec 4.0.0-M11 we solved 5 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12353714 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-2005/ https://repository.apache.org/content/repositories/maven-2005/org/apache/maven/plugins/maven-site-plugin/4.0.0-M11/maven-site-plugin-4.0.0-M11-source-release.zip Source release checksum(s): maven-site-plugin-4.0.0-M11-source-release.zip sha512: fc628fca1fd2c3629a89da9c44b64994e1b5478a7b8f5d465328cdde8064e3f1212768a4053e563160cf08cece96cf8af5a8cd936d9c1b5eafb90bcc922d933f Staging site: https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Reporting Exec version 2.0.0-M11
Hi, IMPORTANT: This require the following staging repositories: * Doxia 2.0.0-M8 * Maven Reporting API 4.0.0-M8 * Doxia Sitetools 2.0.0-M13 * Maven Reporting Impl 4.0.0-M11 we solved 3 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12353712 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-exec Staging repo: https://repository.apache.org/content/repositories/maven-2004/ https://repository.apache.org/content/repositories/maven-2004/org/apache/maven/reporting/maven-reporting-exec/2.0.0-M11/maven-reporting-exec-2.0.0-M11-source-release.zip Source release checksum(s): maven-reporting-exec-2.0.0-M11-source-release.zip sha512: 824ae603848338a3b2addfd4bcdee0dbcfded1b133daf91f8b7189e7cc06b9e3ad59a916f61ee6fb02945d16075fc39edd647551b1489e5c5b22b286fea79746 Staging site: https://maven.apache.org/shared-archives/maven-reporting-exec-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Reporting Impl version 4.0.0-M11
Hi, IMPORTANT: This require the following staging repositories: * Doxia 2.0.0-M8 * Maven Reporting API 4.0.0-M8 * Doxia Sitetools 2.0.0-M13 we solved 5 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12353073 There is one issue left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-impl Staging repo: https://repository.apache.org/content/repositories/maven-2003/ https://repository.apache.org/content/repositories/maven-2003/org/apache/maven/reporting/maven-reporting-impl/4.0.0-M11/maven-reporting-impl-4.0.0-M11-source-release.zip Source release checksum(s): maven-reporting-impl-4.0.0-M11-source-release.zip sha512: 82616775ae4d99aaca9d17aae8efa86c4b435206dfda8367e4e1a56bc44d12806e18566ad568673b092948772e3fcdc1b697defcb2cef51e1d7551e73eeb Staging site: https://maven.apache.org/shared-archives/maven-reporting-impl-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Doxia Sitetools version 2.0.0-M13
IMPORTANT: This require the following staging repositories: * Doxia 2.0.0-M12 * Maven Reporting API 4.0.0-M8 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Doxia Sitetools version 2.0.0-M13
Hi, we solved 3 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12353711 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open Staging repo: https://repository.apache.org/content/repositories/maven-2002 https://repository.apache.org/content/repositories/maven-2002/org/apache/maven/doxia/doxia-sitetools/2.0.0-M13/doxia-sitetools-2.0.0-M13-source-release.zip Source release checksum(s): doxia-sitetools-2.0.0-M13-source-release.zip sha512: 0aa7aa72dd71136acd2ce207ebc01ff893b6f1dbff2a025cf998b4e06103e30924c5bd5030546c349ad7040538fb04b5b06fd877da346dda19ca68d23e08272c Staging site: https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Reporting API version 4.0.0-M8
Hi, IMPORTANT: This require the following staging repositories: * Doxia 2.0.0-M12 we solved 2 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12353698 There are no issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-api Staging repo: https://repository.apache.org/content/repositories/maven-2001/ https://repository.apache.org/content/repositories/maven-2001/org/apache/maven/reporting/maven-reporting-api/4.0.0-M8/maven-reporting-api-4.0.0-M8-source-release.zip Source release checksum(s): maven-reporting-api-4.0.0-M8-source-release.zip sha512: 5a6dfd5dc5182cdf6567b4e0c9dfecc687369360f35a6041566233d6fb05c1eb8e2113b9a434c48acfbb316b4650fcac44e99531ea1a6b62b86fafc363c6ec5f Staging site: https://maven.apache.org/shared-archives/maven-reporting-api-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Doxia version 2.0.0-M8
Hi, we solved 2 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12353657 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-2000/ https://repository.apache.org/content/repositories/maven-2000/org/apache/maven/doxia/doxia/2.0.0-M8/doxia-2.0.0-M8-source-release.zip Source release checksum(s): doxia-2.0.0-M8-source-release.zip sha512: 242d7ba2198a66957f8265812c4bafc52a2fa463bf7a5790cf55df5c8d3f0b022affe57dbaa25060790d1a53ff01c63480c4ee6b38212bd90e97a4f1f54639dd Staging site: https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Le ven. 13 oct. 2023 à 11:07, Tamás Cservenák a
écrit :
> Howdy,
>
> Maven Central supports HTTP/2 for quite some time.
> Google Mirror of Maven Central in the EU has supported HTTP/3 since a while
> ago.
>
> And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for
> example in the sense of used ports, that may be important on farm-sized CI,
> also there is noticeable perf improvement as well), the real boost will be
> probably HTTP/3. Sadly, a year or more ago, when I did perf testing,
> Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today.
>
Until you protect servers against ddos, so we shouldnt benefit from there
and boost is not really in these protocol but more in nio usage where you
get way faster than current sync whetever protocol you use.
> I agree also:
> - jdk/jre client is clearly way to go forward (and is even dependency-less,
> so would make Maven distro even lighter, but unlike wagon-http-lightweight,
> is fully featured)
> - jetty client is "way forward" for those who may want early adoption on
> things like HTTP/3 etc (at the cost of more deps)
>
>
> On Fri, Oct 13, 2023 at 10:50 AM Romain Manni-Bucau >
> wrote:
>
> > Less is better in terms of stack so jre client is the way forward for me,
> > it is fast, reliable and keeps getting enhancements.
> >
> > On http2/3 I dont see it very relevant cause it still gets a lot of
> issues
> > and should be blacklisted for a while until serious mitigations are set
> up
> > on servers.
> >
> > In terms of style, virtual threads are just a default async style which
> is
> > not mainstream and will not for years. It also foes not prevent locking,
> in
> > particular with our current codebase so a full rewrite is relevant if
> there
> > is any will and if not becoming lighter is what is the most relevant.
> >
> > All that to say that staying on jre client, keeping an abstractio is
> what
> > I see as relevant.
> > Other impl can be extensions in an extra repo but sound additional
> > maintenance without end user gain from my window.
> >
> >
> > Le ven. 13 oct. 2023 à 10:30, Michael Osipov a
> > écrit :
> >
> > > I agree that this is a full rewrite, sadly.
> > >
> > > Have you evaluated what degree of logging both JEtty Client and the JDK
> > > Client offer? I consider the JDK client likely as useless in this
> regard.
> > > Don't know about Jetty. At least AHC saved me a lot of trouble...
> > >
> > > On 2023/10/13 08:23:33 Tamás Cservenák wrote:
> > > > And just add more context about transports:
> > > >
> > > > Currently we have Wagon and AHC 4.x ("native") transport in Maven
> > (since
> > > > 3.9). Numbers show that "native" is far superior over Wagon (I think
> we
> > > can
> > > > all agree on this).
> > > >
> > > > Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is
> > one
> > > > of the best HTTP libraries I used), and this implies we are stuck
> with
> > > > HTTP/1.1 only and (probably, hopefully?) bugfix releases only.
> > > Ironically,
> > > > the moment we provided "superior" HTTP transport in Maven, we got
> stuck
> > > at
> > > > the same time. While there is AHC 5.x (sync, that is not HTTP/2
> > capable,
> > > > and async, both require heavy rewrite), switching to it requires
> _full
> > > > rewrite_ as mentioned. Plus the "go async" if you want to leverage
> any
> > > new
> > > > protocol. Basically it is like writing resolver transport from
> scratch.
> > > >
> > > > Hence, I think it is more sane to invest our effort into something
> more
> > > > stable, that at the same time gives us (promises us) future headroom
> as
> > > > well, and IMHO JDK/JRE net.http.HttpClient and (in my experience)
> Jetty
> > > > HttpClient are such things. There is no need for _full rewrite_
> between
> > > > major versions.
> > > >
> > > > In the longer term, this will actually lower the needed effort to
> > > maintain
> > > > these resolver transports, while at the same time prevent us being
> > > cornered
> > > > again.
> > > >
> > > > On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák <
> ta...@cservenak.net>
> > > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > Re perf (and this was already discussed about a year ago, please do
> > not
> > > > > derail discussion): look around
> > > > > https://github.com/apache/maven-resolver/pull/231 and related
> JIRAs,
> > > > > there are the numbers. TL;DR: jetty and jdk clients are
> consistently
> > > > > fastest and are "side by side" (with the benefit of Jetty doing
> > HTTP/3
> > > as
> > > > > well, but with the downside of huge dep trail), while Wagon is
> > > consistently
> > > > > the slowest. Differences wildly differ but are very notable.
> > > > >
> > > > > Personally, I am not interested in doing a full rewrite of existing
> > AHC
> > > > > transport (as the expected amount of bugs doing this is pretty much
> > on
> > > par
> > > > > with doing fully new transport from scratch). I'd rather just
> choose
> > a
> > > > > library with a
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Le ven. 13 oct. 2023 à 11:12, Tamás Cservenák a écrit : > 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... > It still exists and anyone doing images (oci) cares. Jdk still implies dev env whereas here we deliver a plain runtime lib. Jvm can be an in between alternative but jdk sounds too connotated. > my 5 cents. > > On Fri, Oct 13, 2023 at 9:50 AM Romain Manni-Bucau > wrote: > > > s/jdk/jre/ otherwise agree > > > > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák 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 > > > > > 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 > > > wrote: > > > > >> > > > > >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet > > > > > 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 >
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
btw be careful with jdk httpclient as it doesn't really a way to
cleanup resources (see https://bugs.openjdk.org/browse/JDK-8304165)
could be an issue with mvnd
On Fri, 13 Oct 2023 at 19:20, Christoph Läubrich wrote:
>
> You can find JDK http client debugging / configuration options here:
>
> https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html
>
> sadly they seem not configurable per cbut only globally but probably
> someone like to suggest this to the JDK team (e.g. something like
> builder.setProperty(...) )
>
>
> Am 13.10.23 um 10:28 schrieb Michael Osipov:
> > I agree that this is a full rewrite, sadly.
> >
> > Have you evaluated what degree of logging both JEtty Client and the JDK
> > Client offer? I consider the JDK client likely as useless in this regard.
> > Don't know about Jetty. At least AHC saved me a lot of trouble...
> >
> > On 2023/10/13 08:23:33 Tamás Cservenák wrote:
> >> And just add more context about transports:
> >>
> >> Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
> >> 3.9). Numbers show that "native" is far superior over Wagon (I think we can
> >> all agree on this).
> >>
> >> Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
> >> of the best HTTP libraries I used), and this implies we are stuck with
> >> HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
> >> the moment we provided "superior" HTTP transport in Maven, we got stuck at
> >> the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
> >> and async, both require heavy rewrite), switching to it requires _full
> >> rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
> >> protocol. Basically it is like writing resolver transport from scratch.
> >>
> >> Hence, I think it is more sane to invest our effort into something more
> >> stable, that at the same time gives us (promises us) future headroom as
> >> well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> >> HttpClient are such things. There is no need for _full rewrite_ between
> >> major versions.
> >>
> >> In the longer term, this will actually lower the needed effort to maintain
> >> these resolver transports, while at the same time prevent us being cornered
> >> again.
> >>
> >> On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák
> >> wrote:
> >>
> >>> Howdy,
> >>>
> >>> Re perf (and this was already discussed about a year ago, please do not
> >>> derail discussion): look around
> >>> https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
> >>> there are the numbers. TL;DR: jetty and jdk clients are consistently
> >>> fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as
> >>> well, but with the downside of huge dep trail), while Wagon is
> >>> consistently
> >>> the slowest. Differences wildly differ but are very notable.
> >>>
> >>> Personally, I am not interested in doing a full rewrite of existing AHC
> >>> transport (as the expected amount of bugs doing this is pretty much on par
> >>> with doing fully new transport from scratch). I'd rather just choose a
> >>> library with a more stable API, like Jetty is. Moreover, forcing "async"
> >>> style in 2023 is something I'd avoid in today's written Java code (esp
> >>> with
> >>> 21 virtual threads). But sure, if you want to do it, go for it (this work
> >>> would at least move Maven as a project forward, not backward).
> >>>
> >>> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov
> >>> wrote:
> >>>
> Regardless of the names, the following questions code to my mind:
>
> * Does it make sense to put effort into too many clients?
> * How many users will actually switch the client? I bet < 10%
>
> olegk@ and me assessed many times on JIRA that HTTP/2 will have little
> performance benefit for our use case of transport. I'd like to see a move
> to Apache HttpClient 5 Async which does everything, but that is work.
> Having both AHC async and Jetty HTTP Client is a logical overlap and
> unnecessary maintenance burden. While I know nothing about the Jetty
> Client, the AHC (any version) has exceptional logging output down to
> bytes
> of streams which helps very often to analyze problem with users.
>
> I personally refuse and close out issue on JIRA where the user is not
> able to present that kind of debugging information. Poking in the dark.
>
> M
>
> -
> 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
> >
>
>
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
On Fri, 13 Oct 2023 at 19:12, Tamás Cservenák 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 > wrote: > > > s/jdk/jre/ otherwise agree > > > > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák 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 > > > 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 > > > > 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 > > > wrote: > > > > >> > > > > >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet > > > > wrote: > > > > > > > > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák < > > ta...@cservenak.net> > > > a > > > > écrit : > > > > > > > > > Howdy, > > > > > > > > > > As part of
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
You can find JDK http client debugging / configuration options here:
https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html
sadly they seem not configurable per cbut only globally but probably
someone like to suggest this to the JDK team (e.g. something like
builder.setProperty(...) )
Am 13.10.23 um 10:28 schrieb Michael Osipov:
I agree that this is a full rewrite, sadly.
Have you evaluated what degree of logging both JEtty Client and the JDK Client
offer? I consider the JDK client likely as useless in this regard. Don't know
about Jetty. At least AHC saved me a lot of trouble...
On 2023/10/13 08:23:33 Tamás Cservenák wrote:
And just add more context about transports:
Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
3.9). Numbers show that "native" is far superior over Wagon (I think we can
all agree on this).
Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
of the best HTTP libraries I used), and this implies we are stuck with
HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
the moment we provided "superior" HTTP transport in Maven, we got stuck at
the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
and async, both require heavy rewrite), switching to it requires _full
rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
protocol. Basically it is like writing resolver transport from scratch.
Hence, I think it is more sane to invest our effort into something more
stable, that at the same time gives us (promises us) future headroom as
well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
HttpClient are such things. There is no need for _full rewrite_ between
major versions.
In the longer term, this will actually lower the needed effort to maintain
these resolver transports, while at the same time prevent us being cornered
again.
On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák
wrote:
Howdy,
Re perf (and this was already discussed about a year ago, please do not
derail discussion): look around
https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
there are the numbers. TL;DR: jetty and jdk clients are consistently
fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as
well, but with the downside of huge dep trail), while Wagon is consistently
the slowest. Differences wildly differ but are very notable.
Personally, I am not interested in doing a full rewrite of existing AHC
transport (as the expected amount of bugs doing this is pretty much on par
with doing fully new transport from scratch). I'd rather just choose a
library with a more stable API, like Jetty is. Moreover, forcing "async"
style in 2023 is something I'd avoid in today's written Java code (esp with
21 virtual threads). But sure, if you want to do it, go for it (this work
would at least move Maven as a project forward, not backward).
On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov
wrote:
Regardless of the names, the following questions code to my mind:
* Does it make sense to put effort into too many clients?
* How many users will actually switch the client? I bet < 10%
olegk@ and me assessed many times on JIRA that HTTP/2 will have little
performance benefit for our use case of transport. I'd like to see a move
to Apache HttpClient 5 Async which does everything, but that is work.
Having both AHC async and Jetty HTTP Client is a logical overlap and
unnecessary maintenance burden. While I know nothing about the Jetty
Client, the AHC (any version) has exceptional logging output down to bytes
of streams which helps very often to analyze problem with users.
I personally refuse and close out issue on JIRA where the user is not
able to present that kind of debugging information. Poking in the dark.
M
-
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
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
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 wrote: > s/jdk/jre/ otherwise agree > > Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák 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 > > 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 > > > 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 > > wrote: > > > >> > > > >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet > > > 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 ? > > >
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Howdy,
Maven Central supports HTTP/2 for quite some time.
Google Mirror of Maven Central in the EU has supported HTTP/3 since a while
ago.
And while I agree that HTTP/2 over HTTP/1.1 is not huge diff (it is, for
example in the sense of used ports, that may be important on farm-sized CI,
also there is noticeable perf improvement as well), the real boost will be
probably HTTP/3. Sadly, a year or more ago, when I did perf testing,
Jetty12 was still alpha, but I wonder what HTTP/3 numbers would be today.
I agree also:
- jdk/jre client is clearly way to go forward (and is even dependency-less,
so would make Maven distro even lighter, but unlike wagon-http-lightweight,
is fully featured)
- jetty client is "way forward" for those who may want early adoption on
things like HTTP/3 etc (at the cost of more deps)
On Fri, Oct 13, 2023 at 10:50 AM Romain Manni-Bucau
wrote:
> Less is better in terms of stack so jre client is the way forward for me,
> it is fast, reliable and keeps getting enhancements.
>
> On http2/3 I dont see it very relevant cause it still gets a lot of issues
> and should be blacklisted for a while until serious mitigations are set up
> on servers.
>
> In terms of style, virtual threads are just a default async style which is
> not mainstream and will not for years. It also foes not prevent locking, in
> particular with our current codebase so a full rewrite is relevant if there
> is any will and if not becoming lighter is what is the most relevant.
>
> All that to say that staying on jre client, keeping an abstractio is what
> I see as relevant.
> Other impl can be extensions in an extra repo but sound additional
> maintenance without end user gain from my window.
>
>
> Le ven. 13 oct. 2023 à 10:30, Michael Osipov a
> écrit :
>
> > I agree that this is a full rewrite, sadly.
> >
> > Have you evaluated what degree of logging both JEtty Client and the JDK
> > Client offer? I consider the JDK client likely as useless in this regard.
> > Don't know about Jetty. At least AHC saved me a lot of trouble...
> >
> > On 2023/10/13 08:23:33 Tamás Cservenák wrote:
> > > And just add more context about transports:
> > >
> > > Currently we have Wagon and AHC 4.x ("native") transport in Maven
> (since
> > > 3.9). Numbers show that "native" is far superior over Wagon (I think we
> > can
> > > all agree on this).
> > >
> > > Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is
> one
> > > of the best HTTP libraries I used), and this implies we are stuck with
> > > HTTP/1.1 only and (probably, hopefully?) bugfix releases only.
> > Ironically,
> > > the moment we provided "superior" HTTP transport in Maven, we got stuck
> > at
> > > the same time. While there is AHC 5.x (sync, that is not HTTP/2
> capable,
> > > and async, both require heavy rewrite), switching to it requires _full
> > > rewrite_ as mentioned. Plus the "go async" if you want to leverage any
> > new
> > > protocol. Basically it is like writing resolver transport from scratch.
> > >
> > > Hence, I think it is more sane to invest our effort into something more
> > > stable, that at the same time gives us (promises us) future headroom as
> > > well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> > > HttpClient are such things. There is no need for _full rewrite_ between
> > > major versions.
> > >
> > > In the longer term, this will actually lower the needed effort to
> > maintain
> > > these resolver transports, while at the same time prevent us being
> > cornered
> > > again.
> > >
> > > On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Re perf (and this was already discussed about a year ago, please do
> not
> > > > derail discussion): look around
> > > > https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
> > > > there are the numbers. TL;DR: jetty and jdk clients are consistently
> > > > fastest and are "side by side" (with the benefit of Jetty doing
> HTTP/3
> > as
> > > > well, but with the downside of huge dep trail), while Wagon is
> > consistently
> > > > the slowest. Differences wildly differ but are very notable.
> > > >
> > > > Personally, I am not interested in doing a full rewrite of existing
> AHC
> > > > transport (as the expected amount of bugs doing this is pretty much
> on
> > par
> > > > with doing fully new transport from scratch). I'd rather just choose
> a
> > > > library with a more stable API, like Jetty is. Moreover, forcing
> > "async"
> > > > style in 2023 is something I'd avoid in today's written Java code
> (esp
> > with
> > > > 21 virtual threads). But sure, if you want to do it, go for it (this
> > work
> > > > would at least move Maven as a project forward, not backward).
> > > >
> > > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov
> > > > wrote:
> > > >
> > > >> Regardless of the names, the following questions code to my mind:
> > > >>
> > > >> * Does it make sense to put effort into too many clients?
> >
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Less is better in terms of stack so jre client is the way forward for me,
it is fast, reliable and keeps getting enhancements.
On http2/3 I dont see it very relevant cause it still gets a lot of issues
and should be blacklisted for a while until serious mitigations are set up
on servers.
In terms of style, virtual threads are just a default async style which is
not mainstream and will not for years. It also foes not prevent locking, in
particular with our current codebase so a full rewrite is relevant if there
is any will and if not becoming lighter is what is the most relevant.
All that to say that staying on jre client, keeping an abstractio is what
I see as relevant.
Other impl can be extensions in an extra repo but sound additional
maintenance without end user gain from my window.
Le ven. 13 oct. 2023 à 10:30, Michael Osipov a écrit :
> I agree that this is a full rewrite, sadly.
>
> Have you evaluated what degree of logging both JEtty Client and the JDK
> Client offer? I consider the JDK client likely as useless in this regard.
> Don't know about Jetty. At least AHC saved me a lot of trouble...
>
> On 2023/10/13 08:23:33 Tamás Cservenák wrote:
> > And just add more context about transports:
> >
> > Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
> > 3.9). Numbers show that "native" is far superior over Wagon (I think we
> can
> > all agree on this).
> >
> > Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
> > of the best HTTP libraries I used), and this implies we are stuck with
> > HTTP/1.1 only and (probably, hopefully?) bugfix releases only.
> Ironically,
> > the moment we provided "superior" HTTP transport in Maven, we got stuck
> at
> > the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
> > and async, both require heavy rewrite), switching to it requires _full
> > rewrite_ as mentioned. Plus the "go async" if you want to leverage any
> new
> > protocol. Basically it is like writing resolver transport from scratch.
> >
> > Hence, I think it is more sane to invest our effort into something more
> > stable, that at the same time gives us (promises us) future headroom as
> > well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> > HttpClient are such things. There is no need for _full rewrite_ between
> > major versions.
> >
> > In the longer term, this will actually lower the needed effort to
> maintain
> > these resolver transports, while at the same time prevent us being
> cornered
> > again.
> >
> > On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák
> > wrote:
> >
> > > Howdy,
> > >
> > > Re perf (and this was already discussed about a year ago, please do not
> > > derail discussion): look around
> > > https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
> > > there are the numbers. TL;DR: jetty and jdk clients are consistently
> > > fastest and are "side by side" (with the benefit of Jetty doing HTTP/3
> as
> > > well, but with the downside of huge dep trail), while Wagon is
> consistently
> > > the slowest. Differences wildly differ but are very notable.
> > >
> > > Personally, I am not interested in doing a full rewrite of existing AHC
> > > transport (as the expected amount of bugs doing this is pretty much on
> par
> > > with doing fully new transport from scratch). I'd rather just choose a
> > > library with a more stable API, like Jetty is. Moreover, forcing
> "async"
> > > style in 2023 is something I'd avoid in today's written Java code (esp
> with
> > > 21 virtual threads). But sure, if you want to do it, go for it (this
> work
> > > would at least move Maven as a project forward, not backward).
> > >
> > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov
> > > wrote:
> > >
> > >> Regardless of the names, the following questions code to my mind:
> > >>
> > >> * Does it make sense to put effort into too many clients?
> > >> * How many users will actually switch the client? I bet < 10%
> > >>
> > >> olegk@ and me assessed many times on JIRA that HTTP/2 will have
> little
> > >> performance benefit for our use case of transport. I'd like to see a
> move
> > >> to Apache HttpClient 5 Async which does everything, but that is work.
> > >> Having both AHC async and Jetty HTTP Client is a logical overlap and
> > >> unnecessary maintenance burden. While I know nothing about the Jetty
> > >> Client, the AHC (any version) has exceptional logging output down to
> bytes
> > >> of streams which helps very often to analyze problem with users.
> > >>
> > >> I personally refuse and close out issue on JIRA where the user is not
> > >> able to present that kind of debugging information. Poking in the
> dark.
> > >>
> > >> M
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> >
>
>
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
IMHO in contrary: that comparison is perfectly valid as: - this is what Maven end user gets/experiences - you should know that doing checksum extraction in Wagon today is nearly impossible (we could put another 2 year effort into Wagon, but it would only make it "on par" with native transport, maybe, IMHO, not worth it) - both are still HTTP/1.1 only - IMHO, Wagon benefit (of being protocol agnostic) is also it's biggest downside/hurdle as well: whatever new requirement comes in (like checksum extraction was), it is way simpler solved in implementations like "native" (direct use of client library), instead of gleaning thru layers and layers of abstraction and probably adding new layers to solve it (while those layers are what makes "protocol agnostic" thing possible). Today: - resolver needs fast, performant and robust transport, dedicated for that purpose only, we don't want a "swiss army knife" that does everything. - The 2000s with "remote repositories made out of sticks" (httpd + mod_dav, etc) are gone, we can all agree that HTTP protocol is the main transport protocol for artifact transport. Hence, ssh, sftp, DAV, and any other exotic thing loses its importance, as today it is only one liner Docker CLI to spin up a fully fledged MRM. As for logging, for JDK I have no idea (and am somewhat aligned with you here, "probably useless"), while for Jetty I am pretty much sure Jetty devs would not hinder, or better, shoot themselves in their foot, by having their supported product produce obfuscated, unusable or scarce debug logs :) So for Jetty and debug, I'd not be worried. On Fri, Oct 13, 2023 at 10:27 AM Michael Osipov wrote: > You perfectly know that the comparison is not fair because checksum > transport is handled differently. You have to create identical conditions. > > On 2023/10/13 08:11:32 Tamás Cservenák wrote: > > Howdy, > > > > Re perf (and this was already discussed about a year ago, please do not > > derail discussion): look around > > https://github.com/apache/maven-resolver/pull/231 and related JIRAs, > there > > are the numbers. TL;DR: jetty and jdk clients are consistently fastest > and > > are "side by side" (with the benefit of Jetty doing HTTP/3 as well, but > > with the downside of huge dep trail), while Wagon is consistently the > > slowest. Differences wildly differ but are very notable. > > > > Personally, I am not interested in doing a full rewrite of existing AHC > > transport (as the expected amount of bugs doing this is pretty much on > par > > with doing fully new transport from scratch). I'd rather just choose a > > library with a more stable API, like Jetty is. Moreover, forcing "async" > > style in 2023 is something I'd avoid in today's written Java code (esp > with > > 21 virtual threads). But sure, if you want to do it, go for it (this work > > would at least move Maven as a project forward, not backward). > > > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov > wrote: > > > > > Regardless of the names, the following questions code to my mind: > > > > > > * Does it make sense to put effort into too many clients? > > > * How many users will actually switch the client? I bet < 10% > > > > > > olegk@ and me assessed many times on JIRA that HTTP/2 will have little > > > performance benefit for our use case of transport. I'd like to see a > move > > > to Apache HttpClient 5 Async which does everything, but that is work. > > > Having both AHC async and Jetty HTTP Client is a logical overlap and > > > unnecessary maintenance burden. While I know nothing about the Jetty > > > Client, the AHC (any version) has exceptional logging output down to > bytes > > > of streams which helps very often to analyze problem with users. > > > > > > I personally refuse and close out issue on JIRA where the user is not > able > > > to present that kind of debugging information. Poking in the dark. > > > > > > M > > > > > > - > > > 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 > >
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
I agree that this is a full rewrite, sadly.
Have you evaluated what degree of logging both JEtty Client and the JDK Client
offer? I consider the JDK client likely as useless in this regard. Don't know
about Jetty. At least AHC saved me a lot of trouble...
On 2023/10/13 08:23:33 Tamás Cservenák wrote:
> And just add more context about transports:
>
> Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
> 3.9). Numbers show that "native" is far superior over Wagon (I think we can
> all agree on this).
>
> Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
> of the best HTTP libraries I used), and this implies we are stuck with
> HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
> the moment we provided "superior" HTTP transport in Maven, we got stuck at
> the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
> and async, both require heavy rewrite), switching to it requires _full
> rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
> protocol. Basically it is like writing resolver transport from scratch.
>
> Hence, I think it is more sane to invest our effort into something more
> stable, that at the same time gives us (promises us) future headroom as
> well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
> HttpClient are such things. There is no need for _full rewrite_ between
> major versions.
>
> In the longer term, this will actually lower the needed effort to maintain
> these resolver transports, while at the same time prevent us being cornered
> again.
>
> On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák
> wrote:
>
> > Howdy,
> >
> > Re perf (and this was already discussed about a year ago, please do not
> > derail discussion): look around
> > https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
> > there are the numbers. TL;DR: jetty and jdk clients are consistently
> > fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as
> > well, but with the downside of huge dep trail), while Wagon is consistently
> > the slowest. Differences wildly differ but are very notable.
> >
> > Personally, I am not interested in doing a full rewrite of existing AHC
> > transport (as the expected amount of bugs doing this is pretty much on par
> > with doing fully new transport from scratch). I'd rather just choose a
> > library with a more stable API, like Jetty is. Moreover, forcing "async"
> > style in 2023 is something I'd avoid in today's written Java code (esp with
> > 21 virtual threads). But sure, if you want to do it, go for it (this work
> > would at least move Maven as a project forward, not backward).
> >
> > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov
> > wrote:
> >
> >> Regardless of the names, the following questions code to my mind:
> >>
> >> * Does it make sense to put effort into too many clients?
> >> * How many users will actually switch the client? I bet < 10%
> >>
> >> olegk@ and me assessed many times on JIRA that HTTP/2 will have little
> >> performance benefit for our use case of transport. I'd like to see a move
> >> to Apache HttpClient 5 Async which does everything, but that is work.
> >> Having both AHC async and Jetty HTTP Client is a logical overlap and
> >> unnecessary maintenance burden. While I know nothing about the Jetty
> >> Client, the AHC (any version) has exceptional logging output down to bytes
> >> of streams which helps very often to analyze problem with users.
> >>
> >> I personally refuse and close out issue on JIRA where the user is not
> >> able to present that kind of debugging information. Poking in the dark.
> >>
> >> M
> >>
> >> -
> >> 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
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
You perfectly know that the comparison is not fair because checksum transport is handled differently. You have to create identical conditions. On 2023/10/13 08:11:32 Tamás Cservenák wrote: > Howdy, > > Re perf (and this was already discussed about a year ago, please do not > derail discussion): look around > https://github.com/apache/maven-resolver/pull/231 and related JIRAs, there > are the numbers. TL;DR: jetty and jdk clients are consistently fastest and > are "side by side" (with the benefit of Jetty doing HTTP/3 as well, but > with the downside of huge dep trail), while Wagon is consistently the > slowest. Differences wildly differ but are very notable. > > Personally, I am not interested in doing a full rewrite of existing AHC > transport (as the expected amount of bugs doing this is pretty much on par > with doing fully new transport from scratch). I'd rather just choose a > library with a more stable API, like Jetty is. Moreover, forcing "async" > style in 2023 is something I'd avoid in today's written Java code (esp with > 21 virtual threads). But sure, if you want to do it, go for it (this work > would at least move Maven as a project forward, not backward). > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov wrote: > > > Regardless of the names, the following questions code to my mind: > > > > * Does it make sense to put effort into too many clients? > > * How many users will actually switch the client? I bet < 10% > > > > olegk@ and me assessed many times on JIRA that HTTP/2 will have little > > performance benefit for our use case of transport. I'd like to see a move > > to Apache HttpClient 5 Async which does everything, but that is work. > > Having both AHC async and Jetty HTTP Client is a logical overlap and > > unnecessary maintenance burden. While I know nothing about the Jetty > > Client, the AHC (any version) has exceptional logging output down to bytes > > of streams which helps very often to analyze problem with users. > > > > I personally refuse and close out issue on JIRA where the user is not able > > to present that kind of debugging information. Poking in the dark. > > > > M > > > > - > > 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
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
And just add more context about transports:
Currently we have Wagon and AHC 4.x ("native") transport in Maven (since
3.9). Numbers show that "native" is far superior over Wagon (I think we can
all agree on this).
Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one
of the best HTTP libraries I used), and this implies we are stuck with
HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically,
the moment we provided "superior" HTTP transport in Maven, we got stuck at
the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable,
and async, both require heavy rewrite), switching to it requires _full
rewrite_ as mentioned. Plus the "go async" if you want to leverage any new
protocol. Basically it is like writing resolver transport from scratch.
Hence, I think it is more sane to invest our effort into something more
stable, that at the same time gives us (promises us) future headroom as
well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty
HttpClient are such things. There is no need for _full rewrite_ between
major versions.
In the longer term, this will actually lower the needed effort to maintain
these resolver transports, while at the same time prevent us being cornered
again.
On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák
wrote:
> Howdy,
>
> Re perf (and this was already discussed about a year ago, please do not
> derail discussion): look around
> https://github.com/apache/maven-resolver/pull/231 and related JIRAs,
> there are the numbers. TL;DR: jetty and jdk clients are consistently
> fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as
> well, but with the downside of huge dep trail), while Wagon is consistently
> the slowest. Differences wildly differ but are very notable.
>
> Personally, I am not interested in doing a full rewrite of existing AHC
> transport (as the expected amount of bugs doing this is pretty much on par
> with doing fully new transport from scratch). I'd rather just choose a
> library with a more stable API, like Jetty is. Moreover, forcing "async"
> style in 2023 is something I'd avoid in today's written Java code (esp with
> 21 virtual threads). But sure, if you want to do it, go for it (this work
> would at least move Maven as a project forward, not backward).
>
> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov
> wrote:
>
>> Regardless of the names, the following questions code to my mind:
>>
>> * Does it make sense to put effort into too many clients?
>> * How many users will actually switch the client? I bet < 10%
>>
>> olegk@ and me assessed many times on JIRA that HTTP/2 will have little
>> performance benefit for our use case of transport. I'd like to see a move
>> to Apache HttpClient 5 Async which does everything, but that is work.
>> Having both AHC async and Jetty HTTP Client is a logical overlap and
>> unnecessary maintenance burden. While I know nothing about the Jetty
>> Client, the AHC (any version) has exceptional logging output down to bytes
>> of streams which helps very often to analyze problem with users.
>>
>> I personally refuse and close out issue on JIRA where the user is not
>> able to present that kind of debugging information. Poking in the dark.
>>
>> M
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Howdy, Re perf (and this was already discussed about a year ago, please do not derail discussion): look around https://github.com/apache/maven-resolver/pull/231 and related JIRAs, there are the numbers. TL;DR: jetty and jdk clients are consistently fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as well, but with the downside of huge dep trail), while Wagon is consistently the slowest. Differences wildly differ but are very notable. Personally, I am not interested in doing a full rewrite of existing AHC transport (as the expected amount of bugs doing this is pretty much on par with doing fully new transport from scratch). I'd rather just choose a library with a more stable API, like Jetty is. Moreover, forcing "async" style in 2023 is something I'd avoid in today's written Java code (esp with 21 virtual threads). But sure, if you want to do it, go for it (this work would at least move Maven as a project forward, not backward). On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov wrote: > Regardless of the names, the following questions code to my mind: > > * Does it make sense to put effort into too many clients? > * How many users will actually switch the client? I bet < 10% > > olegk@ and me assessed many times on JIRA that HTTP/2 will have little > performance benefit for our use case of transport. I'd like to see a move > to Apache HttpClient 5 Async which does everything, but that is work. > Having both AHC async and Jetty HTTP Client is a logical overlap and > unnecessary maintenance burden. While I know nothing about the Jetty > Client, the AHC (any version) has exceptional logging output down to bytes > of streams which helps very often to analyze problem with users. > > I personally refuse and close out issue on JIRA where the user is not able > to present that kind of debugging information. Poking in the dark. > > M > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Regardless of the names, the following questions code to my mind: * Does it make sense to put effort into too many clients? * How many users will actually switch the client? I bet < 10% olegk@ and me assessed many times on JIRA that HTTP/2 will have little performance benefit for our use case of transport. I'd like to see a move to Apache HttpClient 5 Async which does everything, but that is work. Having both AHC async and Jetty HTTP Client is a logical overlap and unnecessary maintenance burden. While I know nothing about the Jetty Client, the AHC (any version) has exceptional logging output down to bytes of streams which helps very often to analyze problem with users. I personally refuse and close out issue on JIRA where the user is not able to present that kind of debugging information. Poking in the dark. M - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
Inline On Thu, Oct 12, 2023 at 9:52 PM Guillaume Nodet wrote: > Is wagon something we still want to push forward ? > > Definitely not. maven-resolver-transport-wagon JAR should not be added to Maven4 (while Wagon itself AFAIK is sadly still a must due spaghetti in Maven3 Core that is brought over to Maven4). This will make Wagon "invisible" for Resolver. If someone really needs it, can add it (as any other "extra", not shipped by default resolver transport).
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
s/jdk/jre/ otherwise agree Le ven. 13 oct. 2023 à 09:38, Tamás Cservenák 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 > 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 > > 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 > wrote: > > >> > > >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet > > wrote: > > > > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák > 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.
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
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 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 > 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 wrote: > >> > >>> On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet > wrote: > > Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák 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
Re: [DISCUSS] Maven Resolver 2.x HTTP/2 transport modules
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 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 wrote: On Fri, 13 Oct 2023 at 05:52, Guillaume Nodet wrote: Le jeu. 12 oct. 2023 à 21:15, Tamás Cservenák 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
