[jira] [Assigned] (MRESOLVER-587) Memory consumption improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-587: - Assignee: Tamas Cservenak > Memory consumption improvements > --- > > Key: MRESOLVER-587 > URL: https://issues.apache.org/jira/browse/MRESOLVER-587 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > In DataPool, following can be done to reduce memory usage: > * ArtifactDescriptor key does not have to be Artifact instance, is really > just GACEV needed (is identity) > * ArtifactDescriptors could have "interned" the List fields as > well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-586) In typical setups, DefaultArtifact copies the same maps over and over again
[ https://issues.apache.org/jira/browse/MRESOLVER-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-586: - Assignee: Tamas Cservenak > In typical setups, DefaultArtifact copies the same maps over and over again > --- > > Key: MRESOLVER-586 > URL: https://issues.apache.org/jira/browse/MRESOLVER-586 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0, 1.9.21 >Reporter: Guillaume Smet >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > h2. Context > This is part of some work we are trying to do to reduce the build time usage > memory of Quarkus. > We discussed this a bit with Tamas. > While this doesn't constitute a fix for our main issue, it should be an easy > win. > h2. Problem > We have a BOM with 2000+ entries and in `ArtifactDescriptorReaderDelegate`, > the managed dependencies are copied to the descriptors using the `convert` > method that in turn will create a new DefaultArtifact. > Most of these DefaultArtifacts contain a copy of the very same > `type.getProperties()` as they don't have specific artifact properties. > Improving the DefaultArtifact#merge() method to avoid the copy when the > artifact doesn't have any specific properties would already be an easy win. > PR to come. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-586] Avoid copying the type default properties map [maven-resolver]
cstamas merged PR #534: URL: https://github.com/apache/maven-resolver/pull/534 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-586] Avoid copying the type default properties map - 1.9.x [maven-resolver]
cstamas merged PR #535: URL: https://github.com/apache/maven-resolver/pull/535 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRESOLVER-586) In typical setups, DefaultArtifact copies the same maps over and over again
[ https://issues.apache.org/jira/browse/MRESOLVER-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-586. - Resolution: Fixed > In typical setups, DefaultArtifact copies the same maps over and over again > --- > > Key: MRESOLVER-586 > URL: https://issues.apache.org/jira/browse/MRESOLVER-586 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0, 1.9.21 >Reporter: Guillaume Smet >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > h2. Context > This is part of some work we are trying to do to reduce the build time usage > memory of Quarkus. > We discussed this a bit with Tamas. > While this doesn't constitute a fix for our main issue, it should be an easy > win. > h2. Problem > We have a BOM with 2000+ entries and in `ArtifactDescriptorReaderDelegate`, > the managed dependencies are copied to the descriptors using the `convert` > method that in turn will create a new DefaultArtifact. > Most of these DefaultArtifacts contain a copy of the very same > `type.getProperties()` as they don't have specific artifact properties. > Improving the DefaultArtifact#merge() method to avoid the copy when the > artifact doesn't have any specific properties would already be an easy win. > PR to come. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-586) In typical setups, DefaultArtifact copies the same maps over and over again
[ https://issues.apache.org/jira/browse/MRESOLVER-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870431#comment-17870431 ] ASF GitHub Bot commented on MRESOLVER-586: -- cstamas merged PR #534: URL: https://github.com/apache/maven-resolver/pull/534 > In typical setups, DefaultArtifact copies the same maps over and over again > --- > > Key: MRESOLVER-586 > URL: https://issues.apache.org/jira/browse/MRESOLVER-586 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0, 1.9.21 >Reporter: Guillaume Smet >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > h2. Context > This is part of some work we are trying to do to reduce the build time usage > memory of Quarkus. > We discussed this a bit with Tamas. > While this doesn't constitute a fix for our main issue, it should be an easy > win. > h2. Problem > We have a BOM with 2000+ entries and in `ArtifactDescriptorReaderDelegate`, > the managed dependencies are copied to the descriptors using the `convert` > method that in turn will create a new DefaultArtifact. > Most of these DefaultArtifacts contain a copy of the very same > `type.getProperties()` as they don't have specific artifact properties. > Improving the DefaultArtifact#merge() method to avoid the copy when the > artifact doesn't have any specific properties would already be an easy win. > PR to come. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-586) In typical setups, DefaultArtifact copies the same maps over and over again
[ https://issues.apache.org/jira/browse/MRESOLVER-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870432#comment-17870432 ] ASF GitHub Bot commented on MRESOLVER-586: -- cstamas merged PR #535: URL: https://github.com/apache/maven-resolver/pull/535 > In typical setups, DefaultArtifact copies the same maps over and over again > --- > > Key: MRESOLVER-586 > URL: https://issues.apache.org/jira/browse/MRESOLVER-586 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0, 1.9.21 >Reporter: Guillaume Smet >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > h2. Context > This is part of some work we are trying to do to reduce the build time usage > memory of Quarkus. > We discussed this a bit with Tamas. > While this doesn't constitute a fix for our main issue, it should be an easy > win. > h2. Problem > We have a BOM with 2000+ entries and in `ArtifactDescriptorReaderDelegate`, > the managed dependencies are copied to the descriptors using the `convert` > method that in turn will create a new DefaultArtifact. > Most of these DefaultArtifacts contain a copy of the very same > `type.getProperties()` as they don't have specific artifact properties. > Improving the DefaultArtifact#merge() method to avoid the copy when the > artifact doesn't have any specific properties would already be an easy win. > PR to come. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [EXPERIMENT] Just to run MRESOLVER-587 w/ ITs [maven]
cstamas commented on PR #1617: URL: https://github.com/apache/maven/pull/1617#issuecomment-2265014549 Building against latest rebased PR w/ picked up commit -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870435#comment-17870435 ] ASF GitHub Bot commented on MRESOLVER-587: -- cstamas commented on PR #1617: URL: https://github.com/apache/maven/pull/1617#issuecomment-2265014549 Building against latest rebased PR w/ picked up commit > Memory consumption improvements > --- > > Key: MRESOLVER-587 > URL: https://issues.apache.org/jira/browse/MRESOLVER-587 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > In DataPool, following can be done to reduce memory usage: > * ArtifactDescriptor key does not have to be Artifact instance, is really > just GACEV needed (is identity) > * ArtifactDescriptors could have "interned" the List fields as > well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-585) Is unclear how to use custom LocalRepositoryManager with builder
[ https://issues.apache.org/jira/browse/MRESOLVER-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870448#comment-17870448 ] Tamas Cservenak commented on MRESOLVER-585: --- The builder API is wrong. It should NOT accept LocalRepositoryManager, instead, provider of alt LRM should hook into LRMProvider and use custom string for LocalRepository? All in all, this issue seems fluke to me, or at least, the session API is misleading here. > Is unclear how to use custom LocalRepositoryManager with builder > > > Key: MRESOLVER-585 > URL: https://issues.apache.org/jira/browse/MRESOLVER-585 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is > created by system and one needs session for it, but session cannot be created > without LocalRepositoryManager. > Session Builder provides "workaround" in form of withXXX methods, but those > all cannot use custom LocalRepositoryManager... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870457#comment-17870457 ] ASF GitHub Bot commented on MRESOLVER-587: -- cstamas commented on PR #536: URL: https://github.com/apache/maven-resolver/pull/536#issuecomment-2265085629 @gsmet this PR now has it all merged changes, plus, introduces config (defaults to "as before" > Memory consumption improvements > --- > > Key: MRESOLVER-587 > URL: https://issues.apache.org/jira/browse/MRESOLVER-587 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > In DataPool, following can be done to reduce memory usage: > * ArtifactDescriptor key does not have to be Artifact instance, is really > just GACEV needed (is identity) > * ArtifactDescriptors could have "interned" the List fields as > well -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-587] Memory usage improvements [maven-resolver]
cstamas commented on PR #536: URL: https://github.com/apache/maven-resolver/pull/536#issuecomment-2265085629 @gsmet this PR now has it all merged changes, plus, introduces config (defaults to "as before" -- false both) to intern or not intern the artifact descriptor deps list and managedDeps lists. Am tinkering, that maybe feasible default would be false/true (do not intern deps, do intern managedDeps)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-587] Memory usage improvements [maven-resolver]
gsmet commented on PR #536: URL: https://github.com/apache/maven-resolver/pull/536#issuecomment-2265105027 > Am tinkering, that maybe feasible default would be false/true (do not intern deps, do intern managedDeps)? It looks like a good compromise from my side. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870463#comment-17870463 ] ASF GitHub Bot commented on MRESOLVER-587: -- gsmet commented on PR #536: URL: https://github.com/apache/maven-resolver/pull/536#issuecomment-2265105027 > Am tinkering, that maybe feasible default would be false/true (do not intern deps, do intern managedDeps)? It looks like a good compromise from my side. > Memory consumption improvements > --- > > Key: MRESOLVER-587 > URL: https://issues.apache.org/jira/browse/MRESOLVER-587 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > > In DataPool, following can be done to reduce memory usage: > * ArtifactDescriptor key does not have to be Artifact instance, is really > just GACEV needed (is identity) > * ArtifactDescriptors could have "interned" the List fields as > well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-587:
--
Description:
In DataPool, following can be done to reduce memory usage:
* -ArtifactDescriptor key does not have to be Artifact instance, is really
just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
improvement is done introducing new key type.
* ArtifactDescriptors could have "interned" the List fields as well
Latter is done and controlled by two new configuration properties:
* {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
defaults to {{false}}
*
{{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
defaults to {{true}}
Having true/true tremendously improve memory consumption but increases runtime.
was:
In DataPool, following can be done to reduce memory usage:
* ArtifactDescriptor key does not have to be Artifact instance, is really just
GACEV needed (is identity)
* ArtifactDescriptors could have "interned" the List fields as well
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-589) ArtifactDescriptor should be immutable
Tamas Cservenak created MRESOLVER-589: - Summary: ArtifactDescriptor should be immutable Key: MRESOLVER-589 URL: https://issues.apache.org/jira/browse/MRESOLVER-589 Project: Maven Resolver Issue Type: Improvement Reporter: Tamas Cservenak And most probably heavily cached, as on collection of large projects, this leads to insane memory requirements. MRESOLVER-587 and MRESOLVER-586 adds some relief, but still the biggest offender is depMgt that on projects usually get inherited from parent (and can have non trivial size) and is copied over and over again... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-589) ArtifactDescriptorResult should be immutable
[ https://issues.apache.org/jira/browse/MRESOLVER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-589: -- Summary: ArtifactDescriptorResult should be immutable (was: ArtifactDescriptor should be immutable) > ArtifactDescriptorResult should be immutable > > > Key: MRESOLVER-589 > URL: https://issues.apache.org/jira/browse/MRESOLVER-589 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Tamas Cservenak >Priority: Major > > And most probably heavily cached, as on collection of large projects, this > leads to insane memory requirements. MRESOLVER-587 and MRESOLVER-586 adds > some relief, but still the biggest offender is depMgt that on projects > usually get inherited from parent (and can have non trivial size) and is > copied over and over again... -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-587] Memory usage improvements [maven-resolver]
gsmet commented on code in PR #536:
URL: https://github.com/apache/maven-resolver/pull/536#discussion_r1701742710
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DataPool.java:
##
@@ -257,7 +257,7 @@ public static final class DescriptorKey {
private DescriptorKey(Artifact artifact) {
this.artifact = artifact;
-this.hashCode = buildHashCode();
+this.hashCode = Objects.hashCode(artifact);
Review Comment:
Ah yeah sorry, I was used to more complex hashCode construction and kept
this pattern (we avoid using `Objects.hash` as it allocates an array and can be
problematic in some cases so we end up with traditional boilerplate hashCodes).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870476#comment-17870476
]
ASF GitHub Bot commented on MRESOLVER-587:
--
gsmet commented on code in PR #536:
URL: https://github.com/apache/maven-resolver/pull/536#discussion_r1701742710
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DataPool.java:
##
@@ -257,7 +257,7 @@ public static final class DescriptorKey {
private DescriptorKey(Artifact artifact) {
this.artifact = artifact;
-this.hashCode = buildHashCode();
+this.hashCode = Objects.hashCode(artifact);
Review Comment:
Ah yeah sorry, I was used to more complex hashCode construction and kept
this pattern (we avoid using `Objects.hash` as it allocates an array and can be
problematic in some cases so we end up with traditional boilerplate hashCodes).
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-585) Is unclear how to use custom LocalRepositoryManager with builder
[ https://issues.apache.org/jira/browse/MRESOLVER-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-585: - Assignee: Tamas Cservenak > Is unclear how to use custom LocalRepositoryManager with builder > > > Key: MRESOLVER-585 > URL: https://issues.apache.org/jira/browse/MRESOLVER-585 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is > created by system and one needs session for it, but session cannot be created > without LocalRepositoryManager. > Session Builder provides "workaround" in form of withXXX methods, but those > all cannot use custom LocalRepositoryManager... -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-585] Explain reason for this method [maven-resolver]
cstamas merged PR #548: URL: https://github.com/apache/maven-resolver/pull/548 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-585) Is unclear how to use custom LocalRepositoryManager with builder
[ https://issues.apache.org/jira/browse/MRESOLVER-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870480#comment-17870480 ] ASF GitHub Bot commented on MRESOLVER-585: -- cstamas merged PR #548: URL: https://github.com/apache/maven-resolver/pull/548 > Is unclear how to use custom LocalRepositoryManager with builder > > > Key: MRESOLVER-585 > URL: https://issues.apache.org/jira/browse/MRESOLVER-585 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is > created by system and one needs session for it, but session cannot be created > without LocalRepositoryManager. > Session Builder provides "workaround" in form of withXXX methods, but those > all cannot use custom LocalRepositoryManager... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-585) Is unclear how to use custom LocalRepositoryManager with builder
[ https://issues.apache.org/jira/browse/MRESOLVER-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-585. - Resolution: Fixed > Is unclear how to use custom LocalRepositoryManager with builder > > > Key: MRESOLVER-585 > URL: https://issues.apache.org/jira/browse/MRESOLVER-585 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is > created by system and one needs session for it, but session cannot be created > without LocalRepositoryManager. > Session Builder provides "workaround" in form of withXXX methods, but those > all cannot use custom LocalRepositoryManager... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-585) Is unclear how to use custom LocalRepositoryManager with builder
[ https://issues.apache.org/jira/browse/MRESOLVER-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-585: -- Description: We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is created by system and one needs session for it, but session cannot be created without LocalRepositoryManager. Session Builder provides "workaround" in form of withXXX methods, but those all cannot use custom LocalRepositoryManager... In short: this method is "special". The usual way to use custom LRM is to integrate it with LRMProvider and tune it with priorities and/or custom LocalReposirory type strings... was: We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is created by system and one needs session for it, but session cannot be created without LocalRepositoryManager. Session Builder provides "workaround" in form of withXXX methods, but those all cannot use custom LocalRepositoryManager... > Is unclear how to use custom LocalRepositoryManager with builder > > > Key: MRESOLVER-585 > URL: https://issues.apache.org/jira/browse/MRESOLVER-585 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 2.0.0 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > We have a bit of chicken-and-egg problem here, as LocalRepositoryManager is > created by system and one needs session for it, but session cannot be created > without LocalRepositoryManager. > Session Builder provides "workaround" in form of withXXX methods, but those > all cannot use custom LocalRepositoryManager... > In short: this method is "special". The usual way to use custom LRM is to > integrate it with LRMProvider and tune it with priorities and/or custom > LocalReposirory type strings... -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-587] Memory usage improvements [maven-resolver]
cstamas merged PR #537: URL: https://github.com/apache/maven-resolver/pull/537 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870483#comment-17870483
]
ASF GitHub Bot commented on MRESOLVER-587:
--
cstamas merged PR #537:
URL: https://github.com/apache/maven-resolver/pull/537
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-587.
-
Resolution: Fixed
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870484#comment-17870484
]
ASF GitHub Bot commented on MRESOLVER-587:
--
cstamas merged PR #536:
URL: https://github.com/apache/maven-resolver/pull/536
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-587] Memory usage improvements [maven-resolver]
cstamas merged PR #536: URL: https://github.com/apache/maven-resolver/pull/536 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 [maven-resolver]
cstamas merged PR #538: URL: https://github.com/apache/maven-resolver/pull/538 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-590) Bump commons-codec:commons-codec from 1.17.0 to 1.17.1
Tamas Cservenak created MRESOLVER-590: - Summary: Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 Key: MRESOLVER-590 URL: https://issues.apache.org/jira/browse/MRESOLVER-590 Project: Maven Resolver Issue Type: Dependency upgrade Reporter: Tamas Cservenak -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-590) Bump commons-codec:commons-codec from 1.17.0 to 1.17.1
[ https://issues.apache.org/jira/browse/MRESOLVER-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-590: -- Fix Version/s: 2.0.1 1.9.22 > Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 > -- > > Key: MRESOLVER-590 > URL: https://issues.apache.org/jira/browse/MRESOLVER-590 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-590) Bump commons-codec:commons-codec from 1.17.0 to 1.17.1
[ https://issues.apache.org/jira/browse/MRESOLVER-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-590: - Assignee: Tamas Cservenak > Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 > -- > > Key: MRESOLVER-590 > URL: https://issues.apache.org/jira/browse/MRESOLVER-590 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-590) Bump commons-codec:commons-codec from 1.17.0 to 1.17.1
[ https://issues.apache.org/jira/browse/MRESOLVER-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870486#comment-17870486 ] Tamas Cservenak commented on MRESOLVER-590: --- 1.9.x: e8fdfd8e4b6921cbc0ea755b37f75cfd4ac2cd7b master: e8736c157ed04c2646a45fbc7048aa090273ee92 > Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 > -- > > Key: MRESOLVER-590 > URL: https://issues.apache.org/jira/browse/MRESOLVER-590 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-590) Bump commons-codec:commons-codec from 1.17.0 to 1.17.1
[ https://issues.apache.org/jira/browse/MRESOLVER-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-590: -- Component/s: Resolver > Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 > -- > > Key: MRESOLVER-590 > URL: https://issues.apache.org/jira/browse/MRESOLVER-590 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-590) Bump commons-codec:commons-codec from 1.17.0 to 1.17.1
[ https://issues.apache.org/jira/browse/MRESOLVER-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-590. - Resolution: Fixed > Bump commons-codec:commons-codec from 1.17.0 to 1.17.1 > -- > > Key: MRESOLVER-590 > URL: https://issues.apache.org/jira/browse/MRESOLVER-590 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0 [maven-resolver]
cstamas merged PR #541: URL: https://github.com/apache/maven-resolver/pull/541 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-591) Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0
Tamas Cservenak created MRESOLVER-591: - Summary: Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0 Key: MRESOLVER-591 URL: https://issues.apache.org/jira/browse/MRESOLVER-591 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-591) Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0
[ https://issues.apache.org/jira/browse/MRESOLVER-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-591. - Assignee: Tamas Cservenak Resolution: Fixed > Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0 > --- > > Key: MRESOLVER-591 > URL: https://issues.apache.org/jira/browse/MRESOLVER-591 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-591) Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0
[ https://issues.apache.org/jira/browse/MRESOLVER-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870489#comment-17870489 ] Tamas Cservenak commented on MRESOLVER-591: --- master: a4c70e0c6913871ab50c0753fe2243e932ea7ac8 > Bump org.apache.commons:commons-lang3 from 3.14.0 to 3.15.0 > --- > > Key: MRESOLVER-591 > URL: https://issues.apache.org/jira/browse/MRESOLVER-591 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-592) (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to 0.22.0
Tamas Cservenak created MRESOLVER-592: - Summary: (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to 0.22.0 Key: MRESOLVER-592 URL: https://issues.apache.org/jira/browse/MRESOLVER-592 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.1, 1.9.22 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to 0.22.0 [maven-resolver]
cstamas merged PR #543: URL: https://github.com/apache/maven-resolver/pull/543 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-592) (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to 0.22.0
[ https://issues.apache.org/jira/browse/MRESOLVER-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870490#comment-17870490 ] Tamas Cservenak commented on MRESOLVER-592: --- master a1646ce949396d554938598c8b873bf414fe9941 1.9.x: d318fefdf8d544083fff1dc6ca6f02745e9eab60 > (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to > 0.22.0 > - > > Key: MRESOLVER-592 > URL: https://issues.apache.org/jira/browse/MRESOLVER-592 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-592) (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to 0.22.0
[ https://issues.apache.org/jira/browse/MRESOLVER-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-592. - Assignee: Tamas Cservenak Resolution: Fixed > (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.21.2 to > 0.22.0 > - > > Key: MRESOLVER-592 > URL: https://issues.apache.org/jira/browse/MRESOLVER-592 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump testcontainersVersion from 1.19.8 to 1.20.1 [maven-resolver]
cstamas merged PR #546: URL: https://github.com/apache/maven-resolver/pull/546 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-593) (build) Bump testcontainersVersion from 1.19.8 to 1.20.1
Tamas Cservenak created MRESOLVER-593: - Summary: (build) Bump testcontainersVersion from 1.19.8 to 1.20.1 Key: MRESOLVER-593 URL: https://issues.apache.org/jira/browse/MRESOLVER-593 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-593) (build) Bump testcontainersVersion from 1.19.8 to 1.20.1
[ https://issues.apache.org/jira/browse/MRESOLVER-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-593. - Assignee: Tamas Cservenak Resolution: Fixed > (build) Bump testcontainersVersion from 1.19.8 to 1.20.1 > > > Key: MRESOLVER-593 > URL: https://issues.apache.org/jira/browse/MRESOLVER-593 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-594) Bump org.redisson:redisson from 3.32.0 to 3.34.1
Tamas Cservenak created MRESOLVER-594: - Summary: Bump org.redisson:redisson from 3.32.0 to 3.34.1 Key: MRESOLVER-594 URL: https://issues.apache.org/jira/browse/MRESOLVER-594 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.1, 1.9.22 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-593) (build) Bump testcontainersVersion from 1.19.8 to 1.20.1
[ https://issues.apache.org/jira/browse/MRESOLVER-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870491#comment-17870491 ] Tamas Cservenak commented on MRESOLVER-593: --- master e207dd183e9b5e1810a76351ddbb8233ea1f734a > (build) Bump testcontainersVersion from 1.19.8 to 1.20.1 > > > Key: MRESOLVER-593 > URL: https://issues.apache.org/jira/browse/MRESOLVER-593 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.redisson:redisson from 3.32.0 to 3.34.1 [maven-resolver]
cstamas merged PR #547: URL: https://github.com/apache/maven-resolver/pull/547 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-594) Bump org.redisson:redisson from 3.32.0 to 3.34.1
[ https://issues.apache.org/jira/browse/MRESOLVER-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870493#comment-17870493 ] Tamas Cservenak commented on MRESOLVER-594: --- master 4a9f6e89f18a6473f1e2fb6adec4f67f87e509d7 1.9.x 2e045576f3bf58eaf404e9d00d5b6e240733fa32 > Bump org.redisson:redisson from 3.32.0 to 3.34.1 > > > Key: MRESOLVER-594 > URL: https://issues.apache.org/jira/browse/MRESOLVER-594 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-594) Bump org.redisson:redisson from 3.32.0 to 3.34.1
[ https://issues.apache.org/jira/browse/MRESOLVER-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-594. - Assignee: Tamas Cservenak Resolution: Fixed > Bump org.redisson:redisson from 3.32.0 to 3.34.1 > > > Key: MRESOLVER-594 > URL: https://issues.apache.org/jira/browse/MRESOLVER-594 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1, 1.9.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY handling
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870494#comment-17870494
]
Tamas Cservenak commented on MRESOLVER-584:
---
This code change is NOT gonna fix it (as JDK HttpClient cannot handle it even,
see comment above), but it will "easy" the impact for both clients for now...
> Jetty / JDK transport: HTTP2 GOAWAY handling
> -
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-584] JDK transport GOAWAY fix [maven-resolver]
cstamas commented on PR #532: URL: https://github.com/apache/maven-resolver/pull/532#issuecomment-2265243371 Am removing "swap" bit, and will make this pr same as #533 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY handling
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-584:
--
Issue Type: Improvement (was: Bug)
> Jetty / JDK transport: HTTP2 GOAWAY handling
> -
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY handling
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870495#comment-17870495
]
ASF GitHub Bot commented on MRESOLVER-584:
--
cstamas commented on PR #532:
URL: https://github.com/apache/maven-resolver/pull/532#issuecomment-2265243371
Am removing "swap" bit, and will make this pr same as #533
> Jetty / JDK transport: HTTP2 GOAWAY handling
> -
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-584:
--
Summary: Jetty / JDK transport: HTTP2 GOAWAY improvement (was: Jetty /
JDK transport: HTTP2 GOAWAY handling )
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump com.hazelcast:hazelcast from 5.3.7 to 5.5.0 [maven-resolver]
cstamas commented on PR #544: URL: https://github.com/apache/maven-resolver/pull/544#issuecomment-2265284623 Needs Java 11+, so no go for now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-595) Jetty followredirects=2 is too small amount, make it 5 at least
Tamas Cservenak created MRESOLVER-595: - Summary: Jetty followredirects=2 is too small amount, make it 5 at least Key: MRESOLVER-595 URL: https://issues.apache.org/jira/browse/MRESOLVER-595 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-584] JDK transport HTTP/2 GOAWAY improvement [maven-resolver]
cstamas commented on PR #532: URL: https://github.com/apache/maven-resolver/pull/532#issuecomment-2265355335 @scholzi100 am about to merge this one, as I changed JIRA goal also from "fix" to "improve", which this PR does. And later we can refine things even more. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-584] Jetty transport HTTP/2 GOAWAY improvement [maven-resolver]
cstamas commented on PR #533: URL: https://github.com/apache/maven-resolver/pull/533#issuecomment-2265355492 @scholzi100 am about to merge this one, as I changed JIRA goal also from "fix" to "improve", which this PR does. And later we can refine things even more. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-595) Jetty followredirects=2 is too small amount, make it 5 at least (or configurable)
[ https://issues.apache.org/jira/browse/MRESOLVER-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-595: -- Summary: Jetty followredirects=2 is too small amount, make it 5 at least (or configurable) (was: Jetty followredirects=2 is too small amount, make it 5 at least) > Jetty followredirects=2 is too small amount, make it 5 at least (or > configurable) > - > > Key: MRESOLVER-595 > URL: https://issues.apache.org/jira/browse/MRESOLVER-595 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870505#comment-17870505
]
ASF GitHub Bot commented on MRESOLVER-584:
--
cstamas commented on PR #532:
URL: https://github.com/apache/maven-resolver/pull/532#issuecomment-2265355335
@scholzi100 am about to merge this one, as I changed JIRA goal also from
"fix" to "improve", which this PR does. And later we can refine things even
more.
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870506#comment-17870506
]
ASF GitHub Bot commented on MRESOLVER-584:
--
cstamas commented on PR #533:
URL: https://github.com/apache/maven-resolver/pull/533#issuecomment-2265355492
@scholzi100 am about to merge this one, as I changed JIRA goal also from
"fix" to "improve", which this PR does. And later we can refine things even
more.
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7344] track dependencyManagement import location in effective Model for MPH-183 [maven]
juulhobert commented on PR #603: URL: https://github.com/apache/maven/pull/603#issuecomment-2265378877 @mthmulders can you please run the failed integration tests again? I expect it to give a green check mark this time (see https://github.com/infosupport/maven/actions/runs/10215678351) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870509#comment-17870509 ] ASF GitHub Bot commented on MNG-7344: - juulhobert commented on PR #603: URL: https://github.com/apache/maven/pull/603#issuecomment-2265378877 @mthmulders can you please run the failed integration tests again? I expect it to give a green check mark this time (see https://github.com/infosupport/maven/actions/runs/10215678351) > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked though InputLocation, > as done in MNG-1803, later displayed by verbose help effective-pom with > MPH-160 > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-584] JDK transport HTTP/2 GOAWAY improvement [maven-resolver]
cstamas merged PR #532: URL: https://github.com/apache/maven-resolver/pull/532 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-584] Jetty transport HTTP/2 GOAWAY improvement [maven-resolver]
cstamas merged PR #533: URL: https://github.com/apache/maven-resolver/pull/533 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870512#comment-17870512
]
ASF GitHub Bot commented on MRESOLVER-584:
--
cstamas merged PR #532:
URL: https://github.com/apache/maven-resolver/pull/532
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870513#comment-17870513
]
ASF GitHub Bot commented on MRESOLVER-584:
--
cstamas merged PR #533:
URL: https://github.com/apache/maven-resolver/pull/533
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870514#comment-17870514
]
Tamas Cservenak commented on MRESOLVER-584:
---
To recap: changes merged as part of this JIRA do not fix the problem (as Jdk
HttpClient cannot, as it currently does not handle it). Hence the issue goal
changed from "fix" to "improve", and it improves but (radically) shortening
life span of HTTP2 clients, that were originally kept alive across whole
duration of session, but now (as any other transport by the way) are kept alive
as long as Transport is kept alive.
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-584) Jetty / JDK transport: HTTP2 GOAWAY improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-584.
-
Resolution: Fixed
> Jetty / JDK transport: HTTP2 GOAWAY improvement
>
>
> Key: MRESOLVER-584
> URL: https://issues.apache.org/jira/browse/MRESOLVER-584
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3, 2.0.0-alpha-4,
> 2.0.0-alpha-5, 2.0.0-alpha-6, 2.0.0-alpha-7, 2.0.0-alpha-8, 2.0.0,
> 2.0.0-alpha-9, 2.0.0-alpha-10, 2.0.0-alpha-11
>Reporter: Paul Scholz
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: exception.log, exception_jetty.log
>
>
> I am encountering a problem with the implementation of JDK transport using
> HTTP/2, specifically related to re-establishing connections after receiving a
> GOAWAY frame. (RFC quote below)
> Just for example a nginx server with default configuration does only allow
> 1000 requests per connection before requiring "establishing a new connection".
> This results in IOException, stopping resolution process: [^exception.log].
> {code:java}
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:586)
> at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.send(JdkTransporter.java:392)
> at
> org.eclipse.aether.transport.jdk.JdkTransporter.implGet(JdkTransporter.java:271)
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:64)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:501)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:433)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(Thread.java:840)
> Caused by: java.io.IOException: /10.8.2.106:51760: GOAWAY received
> at
> jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1009)
> at
> jdk.internal.net.http.Http2Connection.handleConnectionFrame(Http2Connection.java:874)
> at
> jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:749)
> ...
> {code}
> Related to: [How to handle HTTP/2 GOAWAY with
> java.net.HttpClient?|https://stackoverflow.com/a/55092354]
>
> {quote}Sets the maximum number of requests (...) that can be served through
> one HTTP/2 connection, after which the next client request will lead to
> connection closing and the need of establishing a new connection.
> --
> [https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests|http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests]
> [–
> https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests|https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {quote}
>
> {quote}Once sent, the sender will ignore frames sent on streams initiated by
> the receiver if the stream has an identifier higher than the included last
> stream identifier. Receivers of a GOAWAY frame MUST NOT open additional
> streams on the connection, although a new connection can be established for
> new streams.
> – [RFC 7540 6.7|https://datatracker.ietf.org/doc/html/rfc7540#section-6.8]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-595) Jetty transport should expose config for redirect follow and max redirects
[ https://issues.apache.org/jira/browse/MRESOLVER-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-595: -- Summary: Jetty transport should expose config for redirect follow and max redirects (was: Jetty followredirects=2 is too small amount, make it 5 at least (or configurable)) > Jetty transport should expose config for redirect follow and max redirects > -- > > Key: MRESOLVER-595 > URL: https://issues.apache.org/jira/browse/MRESOLVER-595 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MRESOLVER-595] Expose follow and max redirects for Jetty client [maven-resolver]
cstamas opened a new pull request, #549: URL: https://github.com/apache/maven-resolver/pull/549 --- https://issues.apache.org/jira/browse/MRESOLVER-595 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-595) Jetty transport should expose config for redirect follow and max redirects
[ https://issues.apache.org/jira/browse/MRESOLVER-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870518#comment-17870518 ] ASF GitHub Bot commented on MRESOLVER-595: -- cstamas opened a new pull request, #549: URL: https://github.com/apache/maven-resolver/pull/549 --- https://issues.apache.org/jira/browse/MRESOLVER-595 > Jetty transport should expose config for redirect follow and max redirects > -- > > Key: MRESOLVER-595 > URL: https://issues.apache.org/jira/browse/MRESOLVER-595 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-595] Expose follow and max redirects for Jetty client [maven-resolver]
cstamas merged PR #549: URL: https://github.com/apache/maven-resolver/pull/549 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-595) Jetty transport should expose config for redirect follow and max redirects
[ https://issues.apache.org/jira/browse/MRESOLVER-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870520#comment-17870520 ] ASF GitHub Bot commented on MRESOLVER-595: -- cstamas merged PR #549: URL: https://github.com/apache/maven-resolver/pull/549 > Jetty transport should expose config for redirect follow and max redirects > -- > > Key: MRESOLVER-595 > URL: https://issues.apache.org/jira/browse/MRESOLVER-595 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-595) Jetty transport should expose config for redirect follow and max redirects
[ https://issues.apache.org/jira/browse/MRESOLVER-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-595. - Assignee: Tamas Cservenak Resolution: Fixed > Jetty transport should expose config for redirect follow and max redirects > -- > > Key: MRESOLVER-595 > URL: https://issues.apache.org/jira/browse/MRESOLVER-595 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-588] Add env-variables as sys-props in Maven-4 SessionBuilderSupplier [maven-resolver]
cstamas commented on PR #539: URL: https://github.com/apache/maven-resolver/pull/539#issuecomment-2265456429 Personally, I'd skip doing this altogether and here is why: * as i see in Maven4 supplier (plus Maven side of bits) this is not happening at all * the goal of supplier is to provide "baseline" only, and nothing in Resolver uses ENV variables * the idea is that _user_ who needs env or whatever, just _customize supplier by overriding required method_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-588) Incomplete system properties in SessionBuilderSupplier
[
https://issues.apache.org/jira/browse/MRESOLVER-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870525#comment-17870525
]
ASF GitHub Bot commented on MRESOLVER-588:
--
cstamas commented on PR #539:
URL: https://github.com/apache/maven-resolver/pull/539#issuecomment-2265456429
Personally, I'd skip doing this altogether and here is why:
* as i see in Maven4 supplier (plus Maven side of bits) this is not
happening at all
* the goal of supplier is to provide "baseline" only, and nothing in
Resolver uses ENV variables
* the idea is that _user_ who needs env or whatever, just _customize
supplier by overriding required method_
> Incomplete system properties in SessionBuilderSupplier
> --
>
> Key: MRESOLVER-588
> URL: https://issues.apache.org/jira/browse/MRESOLVER-588
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 2.0.0
>Reporter: Hannes Wellmann
>Priority: Major
>
> The {{SessionBuilderSupplier}} provided for Maven3 sets the java
> System.properties as systemProperties of the Session to be build.
> [https://github.com/apache/maven-resolver/blob/d13019ce5fa38c0951ca0fb0c62a3f5f1254cffc/maven-resolver-supplier-mvn3/src/main/java/org/eclipse/aether/supplier/SessionBuilderSupplier.java#L72]
> But it does not add environment variables with their key prefixed with
> {{env.}} like it is for example done in Maven or MIMA:
> [https://github.com/maveniverse/mima/blob/e851dee08706024929f1004e18e3dbd7b3522b36/runtime/standalone-shared/src/main/java/eu/maveniverse/maven/mima/runtime/shared/StandaloneRuntimeSupport.java#L519-L530]
>
> From looking at the code of the SessionBuilderSupplier for Maven 4, which
> relys heavily on
> {{org.apache.maven.repository.internal.MavenSessionBuilderSupplier }}system
> properties are not set at all.
> My suggestion is to extend the Maven3 SessionBuilderSupplier in
> Maven-Resolver and in maven4 {{MavenSessionBuilderSupplier to have
> system-properties and environment variables fully set by default.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on PR #762: URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2265495092 I guess @slawekjaranowski is on vacation. Let's leave him sometime to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870536#comment-17870536
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2265495092
I guess @slawekjaranowski is on vacation. Let's leave him sometime to review.
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
> on SUREFIRE-1385 branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-529) Add new report goal 'report-no-fork' which will not invoke process-classes
[ https://issues.apache.org/jira/browse/MPLUGIN-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870538#comment-17870538 ] ASF GitHub Bot commented on MPLUGIN-529: michael-o commented on PR #312: URL: https://github.com/apache/maven-plugin-tools/pull/312#issuecomment-2265498773 @mattnelson I would be worthwhile to backport he annotations patch to the 3.x branch as well. > Add new report goal 'report-no-fork' which will not invoke process-classes > -- > > Key: MPLUGIN-529 > URL: https://issues.apache.org/jira/browse/MPLUGIN-529 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Reporting Plugin >Reporter: Matt Nelson >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 3.14.0, 4.0.0-beta-2 > > > Identical root issues as MJAVADOC-369 and JXR-143 > Add new goal which does not fork the build when those phases have already > executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-529] Add new report goal 'report-no-fork' which will not invoke process-classes [maven-plugin-tools]
michael-o commented on PR #312: URL: https://github.com/apache/maven-plugin-tools/pull/312#issuecomment-2265498773 @mattnelson I would be worthwhile to backport he annotations patch to the 3.x branch as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-541) S3 Transport
[ https://issues.apache.org/jira/browse/MRESOLVER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-541: -- Labels: up-for-grabs (was: ) > S3 Transport > > > Key: MRESOLVER-541 > URL: https://issues.apache.org/jira/browse/MRESOLVER-541 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Labels: up-for-grabs > > We might want to revisit creating transport for S3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [EXPERIMENT] Just to run MRESOLVER-587 w/ ITs [maven]
cstamas closed pull request #1617: [EXPERIMENT] Just to run MRESOLVER-587 w/ ITs URL: https://github.com/apache/maven/pull/1617 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [EXPERIMENT] Just to run MRESOLVER-587 w/ ITs [maven]
cstamas commented on PR #1617: URL: https://github.com/apache/maven/pull/1617#issuecomment-2265567223 Experiment done, all looks good. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870548#comment-17870548
]
ASF GitHub Bot commented on MRESOLVER-587:
--
cstamas closed pull request #1617: [EXPERIMENT] Just to run MRESOLVER-587 w/ ITs
URL: https://github.com/apache/maven/pull/1617
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-587) Memory consumption improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870549#comment-17870549
]
ASF GitHub Bot commented on MRESOLVER-587:
--
cstamas commented on PR #1617:
URL: https://github.com/apache/maven/pull/1617#issuecomment-2265567223
Experiment done, all looks good.
> Memory consumption improvements
> ---
>
> Key: MRESOLVER-587
> URL: https://issues.apache.org/jira/browse/MRESOLVER-587
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.1, 1.9.22
>
>
> In DataPool, following can be done to reduce memory usage:
> * -ArtifactDescriptor key does not have to be Artifact instance, is really
> just GACEV needed (is identity)- WRONG, it must be Artifact. Still, some
> improvement is done introducing new key type.
> * ArtifactDescriptors could have "interned" the List fields as
> well
> Latter is done and controlled by two new configuration properties:
> * {{aether.dependencyCollector.pool.internArtifactDescriptorDependencies}}
> defaults to {{false}}
> *
> {{aether.dependencyCollector.pool.internArtifactDescriptorManagedDependencies}}
> defaults to {{true}}
> Having true/true tremendously improve memory consumption but increases
> runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] [discussion] run mvnd in docker [maven-mvnd]
wallentx commented on issue #496: URL: https://github.com/apache/maven-mvnd/issues/496#issuecomment-2265607381 Yo I literally just stumbled upon this https://github.com/fbricon/mvn-cache-test https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html https://maven.apache.org/resolver/ https://maven.apache.org/extensions/maven-build-cache-extension/remote-cache.html This might solve my thing, but I wonder if there are working parts here that mavend could piggyback on -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MWRAPPER-145) Allow for sha512 checksum verification of downloaded artifacts
Brian Demers created MWRAPPER-145: - Summary: Allow for sha512 checksum verification of downloaded artifacts Key: MWRAPPER-145 URL: https://issues.apache.org/jira/browse/MWRAPPER-145 Project: Maven Wrapper Issue Type: Improvement Reporter: Brian Demers The wrapper supports both dist and wrapper jar sha256 checksums for download verification. This is great but only `sha512` (and legacy sha1, md5) checksums are published to the Apache dist servers (linked from [https://maven.apache.org/download.cgi)] and available on Maven Central (opinion: because the above we should favor sha512) Similar to: MWRAPPER-75 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-529] Add new report goal 'report-no-fork' which will not invoke process-classes [maven-plugin-tools]
michael-o commented on PR #312: URL: https://github.com/apache/maven-plugin-tools/pull/312#issuecomment-2266132339 I have discovered a few more cleanups required prior this can be merged. Please stay put. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-529) Add new report goal 'report-no-fork' which will not invoke process-classes
[ https://issues.apache.org/jira/browse/MPLUGIN-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870624#comment-17870624 ] ASF GitHub Bot commented on MPLUGIN-529: michael-o commented on PR #312: URL: https://github.com/apache/maven-plugin-tools/pull/312#issuecomment-2266132339 I have discovered a few more cleanups required prior this can be merged. Please stay put. > Add new report goal 'report-no-fork' which will not invoke process-classes > -- > > Key: MPLUGIN-529 > URL: https://issues.apache.org/jira/browse/MPLUGIN-529 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Reporting Plugin >Reporter: Matt Nelson >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 3.14.0, 4.0.0-beta-2 > > > Identical root issues as MJAVADOC-369 and JXR-143 > Add new goal which does not fork the build when those phases have already > executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.codehaus.plexus:plexus-testing from 1.3.0 to 1.4.0 [maven-plugin-tools]
michael-o commented on PR #303: URL: https://github.com/apache/maven-plugin-tools/pull/303#issuecomment-2266163300 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-testing from 1.3.0 to 1.4.0 [maven-plugin-tools]
asfgit merged PR #303: URL: https://github.com/apache/maven-plugin-tools/pull/303 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-archiver from 4.9.2 to 4.10.0 [maven-plugin-tools]
michael-o commented on PR #304: URL: https://github.com/apache/maven-plugin-tools/pull/304#issuecomment-2266165034 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-archiver from 4.9.2 to 4.10.0 [maven-plugin-tools]
asfgit merged PR #304: URL: https://github.com/apache/maven-plugin-tools/pull/304 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.jsoup:jsoup from 1.17.2 to 1.18.1 [maven-plugin-tools]
michael-o commented on PR #307: URL: https://github.com/apache/maven-plugin-tools/pull/307#issuecomment-2266166409 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.jsoup:jsoup from 1.17.2 to 1.18.1 [maven-plugin-tools]
asfgit merged PR #307: URL: https://github.com/apache/maven-plugin-tools/pull/307 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
