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
> 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
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:
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
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:
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
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:
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:
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:
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
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
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:
>
>
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
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
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
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
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
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,
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
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):
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
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
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
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
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
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
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:
28 matches
Mail list logo
