[GitHub] [maven] slawekjaranowski commented on a diff in pull request #768: [MNG-7509] - Huge memory cost when parent pom widely used in a big project for dependencyManagement for maven-3.9.x
slawekjaranowski commented on code in PR #768: URL: https://github.com/apache/maven/pull/768#discussion_r928105177 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: please put imports before license. -- 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-7509) Huge memory cost when parent pom widely used in a big project for dependencyManagement
[ https://issues.apache.org/jira/browse/MNG-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570282#comment-17570282 ] ASF GitHub Bot commented on MNG-7509: - slawekjaranowski commented on code in PR #768: URL: https://github.com/apache/maven/pull/768#discussion_r928105177 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: please put imports before license. > Huge memory cost when parent pom widely used in a big project for > dependencyManagement > -- > > Key: MNG-7509 > URL: https://issues.apache.org/jira/browse/MNG-7509 > Project: Maven > Issue Type: Improvement > Components: Performance >Reporter: Xiong Luyao >Priority: Critical > Attachments: image-2022-07-09-09-37-53-823.png, > image-2022-07-09-09-38-26-354.png, image-2022-07-09-10-27-12-668.png, > image-2022-07-09-10-27-56-437.png, image-2022-07-09-10-28-05-706.png, > image-2022-07-09-10-28-22-864.png, image-2022-07-09-10-28-35-341.png, > image-2022-07-09-10-28-40-612.png, image-2022-07-09-10-29-04-045.png, > image-2022-07-09-10-29-15-822.png, image-2022-07-09-10-29-21-991.png, > image-2022-07-09-10-29-46-216.png, image-2022-07-09-10-29-51-456.png > > > When maven try to resolve dependency relationship, it will create many > instances of dependency / artifact, even the dependency/artifact content is > totally same, but just in different pom models. It cost huge memory if there > is a parent pom with dependencyManagement which managed a lot of > dependencies, and this parent pom are implemented by many project libraries. > (libraries_count * managedDependency_count) dependency instances will be > created. For example, if there are 3000 libraries, and all the library > introduce same parent pom which managed 3000 dependencies version. There will > be 3000*3000 =9,000,000 dependency instances will be created. But most of > them are same, in fact, we only need one instance for each dependency in > parent pom (3000 dependency instances). > > I'm from eBay, and here is a real case in enterprise level project. We have > about 3000 business domain libraries, there are dependency relationship > between them. We need to build all libraries in one release to keep all the > libraries in same release are based on same code. So we used a parent pom as > a central management to manage all the version for a release, and introduced > by those libraries. As below picture, when the release start, it will > calculate and start with the library which doesn't depend on others, then > start the library which dependency libraries are already built. Keep this > process until all libraries are built. > With current maven resolve logic, it costs huge memory in above ways to built > libraries. And even the libraries have been released, if the project which > contains a lot of above libraries, it also cost huge memory when building > project. > So current now, we have to specify version in each library pom files instead > of using parent pom. We think we can make some enhancement for this case. > > !image-2022-07-09-09-37-53-823.png|width=493,height=226! > > Here is a thread dump when building a real project which depends on about > 1000 above libraries. The top 5 objects are all related to > org.eclipse.aether.graph.Dependency. > !image-2022-07-09-09-38-26-354.png|width=510,height=199! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #764: [MNG-7509] - Huge memory cost when parent pom widely used in a big project for dependencyManagement for 3.8.x
slawekjaranowski commented on code in PR #764: URL: https://github.com/apache/maven/pull/764#discussion_r928105299 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: please put imports after license. -- 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
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #768: [MNG-7509] - Huge memory cost when parent pom widely used in a big project for dependencyManagement for maven-3.9.x
slawekjaranowski commented on code in PR #768: URL: https://github.com/apache/maven/pull/768#discussion_r928105177 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: please put imports after license. -- 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-7509) Huge memory cost when parent pom widely used in a big project for dependencyManagement
[ https://issues.apache.org/jira/browse/MNG-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570284#comment-17570284 ] ASF GitHub Bot commented on MNG-7509: - slawekjaranowski commented on code in PR #768: URL: https://github.com/apache/maven/pull/768#discussion_r928105177 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: please put imports after license. > Huge memory cost when parent pom widely used in a big project for > dependencyManagement > -- > > Key: MNG-7509 > URL: https://issues.apache.org/jira/browse/MNG-7509 > Project: Maven > Issue Type: Improvement > Components: Performance >Reporter: Xiong Luyao >Priority: Critical > Attachments: image-2022-07-09-09-37-53-823.png, > image-2022-07-09-09-38-26-354.png, image-2022-07-09-10-27-12-668.png, > image-2022-07-09-10-27-56-437.png, image-2022-07-09-10-28-05-706.png, > image-2022-07-09-10-28-22-864.png, image-2022-07-09-10-28-35-341.png, > image-2022-07-09-10-28-40-612.png, image-2022-07-09-10-29-04-045.png, > image-2022-07-09-10-29-15-822.png, image-2022-07-09-10-29-21-991.png, > image-2022-07-09-10-29-46-216.png, image-2022-07-09-10-29-51-456.png > > > When maven try to resolve dependency relationship, it will create many > instances of dependency / artifact, even the dependency/artifact content is > totally same, but just in different pom models. It cost huge memory if there > is a parent pom with dependencyManagement which managed a lot of > dependencies, and this parent pom are implemented by many project libraries. > (libraries_count * managedDependency_count) dependency instances will be > created. For example, if there are 3000 libraries, and all the library > introduce same parent pom which managed 3000 dependencies version. There will > be 3000*3000 =9,000,000 dependency instances will be created. But most of > them are same, in fact, we only need one instance for each dependency in > parent pom (3000 dependency instances). > > I'm from eBay, and here is a real case in enterprise level project. We have > about 3000 business domain libraries, there are dependency relationship > between them. We need to build all libraries in one release to keep all the > libraries in same release are based on same code. So we used a parent pom as > a central management to manage all the version for a release, and introduced > by those libraries. As below picture, when the release start, it will > calculate and start with the library which doesn't depend on others, then > start the library which dependency libraries are already built. Keep this > process until all libraries are built. > With current maven resolve logic, it costs huge memory in above ways to built > libraries. And even the libraries have been released, if the project which > contains a lot of above libraries, it also cost huge memory when building > project. > So current now, we have to specify version in each library pom files instead > of using parent pom. We think we can make some enhancement for this case. > > !image-2022-07-09-09-37-53-823.png|width=493,height=226! > > Here is a thread dump when building a real project which depends on about > 1000 above libraries. The top 5 objects are all related to > org.eclipse.aether.graph.Dependency. > !image-2022-07-09-09-38-26-354.png|width=510,height=199! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7509) Huge memory cost when parent pom widely used in a big project for dependencyManagement
[ https://issues.apache.org/jira/browse/MNG-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570283#comment-17570283 ] ASF GitHub Bot commented on MNG-7509: - slawekjaranowski commented on code in PR #764: URL: https://github.com/apache/maven/pull/764#discussion_r928105299 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: please put imports after license. > Huge memory cost when parent pom widely used in a big project for > dependencyManagement > -- > > Key: MNG-7509 > URL: https://issues.apache.org/jira/browse/MNG-7509 > Project: Maven > Issue Type: Improvement > Components: Performance >Reporter: Xiong Luyao >Priority: Critical > Attachments: image-2022-07-09-09-37-53-823.png, > image-2022-07-09-09-38-26-354.png, image-2022-07-09-10-27-12-668.png, > image-2022-07-09-10-27-56-437.png, image-2022-07-09-10-28-05-706.png, > image-2022-07-09-10-28-22-864.png, image-2022-07-09-10-28-35-341.png, > image-2022-07-09-10-28-40-612.png, image-2022-07-09-10-29-04-045.png, > image-2022-07-09-10-29-15-822.png, image-2022-07-09-10-29-21-991.png, > image-2022-07-09-10-29-46-216.png, image-2022-07-09-10-29-51-456.png > > > When maven try to resolve dependency relationship, it will create many > instances of dependency / artifact, even the dependency/artifact content is > totally same, but just in different pom models. It cost huge memory if there > is a parent pom with dependencyManagement which managed a lot of > dependencies, and this parent pom are implemented by many project libraries. > (libraries_count * managedDependency_count) dependency instances will be > created. For example, if there are 3000 libraries, and all the library > introduce same parent pom which managed 3000 dependencies version. There will > be 3000*3000 =9,000,000 dependency instances will be created. But most of > them are same, in fact, we only need one instance for each dependency in > parent pom (3000 dependency instances). > > I'm from eBay, and here is a real case in enterprise level project. We have > about 3000 business domain libraries, there are dependency relationship > between them. We need to build all libraries in one release to keep all the > libraries in same release are based on same code. So we used a parent pom as > a central management to manage all the version for a release, and introduced > by those libraries. As below picture, when the release start, it will > calculate and start with the library which doesn't depend on others, then > start the library which dependency libraries are already built. Keep this > process until all libraries are built. > With current maven resolve logic, it costs huge memory in above ways to built > libraries. And even the libraries have been released, if the project which > contains a lot of above libraries, it also cost huge memory when building > project. > So current now, we have to specify version in each library pom files instead > of using parent pom. We think we can make some enhancement for this case. > > !image-2022-07-09-09-37-53-823.png|width=493,height=226! > > Here is a thread dump when building a real project which depends on about > 1000 above libraries. The top 5 objects are all related to > org.eclipse.aether.graph.Dependency. > !image-2022-07-09-09-38-26-354.png|width=510,height=199! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-393) Upgrade to JUnit 5 and @Inject annotations
[ https://issues.apache.org/jira/browse/MPLUGIN-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MPLUGIN-393: Summary: Upgrade to JUnit 5 and @Inject annotations (was: Upgrade to JDK8, junit 5 and @Inject annotations) > Upgrade to JUnit 5 and @Inject annotations > --- > > Key: MPLUGIN-393 > URL: https://issues.apache.org/jira/browse/MPLUGIN-393 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-340) Remove test-javadoc reports
Slawomir Jaranowski created MPOM-340:
Summary: Remove test-javadoc reports
Key: MPOM-340
URL: https://issues.apache.org/jira/browse/MPOM-340
Project: Maven POMs
Issue Type: Improvement
Components: maven
Reporter: Slawomir Jaranowski
When we use JUnit 5 test classes can be package private, in this case we will
have error:
{code}
[ERROR] Exit code: 1 - javadoc: error - No public or protected classes found to
document.
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] slawekjaranowski merged pull request #124: [MPLUGIN-411] Get rid of plexus-compiler-manager from tests
slawekjaranowski merged PR #124: URL: https://github.com/apache/maven-plugin-tools/pull/124 -- 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] (MPLUGIN-411) Get rid of plexus-compiler-manager from tests
[ https://issues.apache.org/jira/browse/MPLUGIN-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPLUGIN-411. --- Fix Version/s: 3.7.0 Resolution: Fixed > Get rid of plexus-compiler-manager from tests > - > > Key: MPLUGIN-411 > URL: https://issues.apache.org/jira/browse/MPLUGIN-411 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > External dependency like plexus-compiler-manager no need to be used in tests. > The most of it tests used very old version of it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-411) Get rid of plexus-compiler-manager from tests
[ https://issues.apache.org/jira/browse/MPLUGIN-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570292#comment-17570292 ] ASF GitHub Bot commented on MPLUGIN-411: slawekjaranowski merged PR #124: URL: https://github.com/apache/maven-plugin-tools/pull/124 > Get rid of plexus-compiler-manager from tests > - > > Key: MPLUGIN-411 > URL: https://issues.apache.org/jira/browse/MPLUGIN-411 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > > External dependency like plexus-compiler-manager no need to be used in tests. > The most of it tests used very old version of it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-plugin-tools] dependabot[bot] commented on pull request #122: Bump plexus-compiler-manager from 2.8.8 to 2.12.1
dependabot[bot] commented on PR #122: URL: https://github.com/apache/maven-plugin-tools/pull/122#issuecomment-1193114609 Looks like org.codehaus.plexus:plexus-compiler-manager is no longer a dependency, so this is no longer needed. -- 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
[GitHub] [maven-plugin-tools] dependabot[bot] closed pull request #122: Bump plexus-compiler-manager from 2.8.8 to 2.12.1
dependabot[bot] closed pull request #122: Bump plexus-compiler-manager from 2.8.8 to 2.12.1 URL: https://github.com/apache/maven-plugin-tools/pull/122 -- 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-411) Get rid of plexus-compiler-manager from tests
[ https://issues.apache.org/jira/browse/MPLUGIN-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570294#comment-17570294 ] Hudson commented on MPLUGIN-411: Build succeeded in Jenkins: Maven » Maven TLP » maven-plugin-tools » master #34 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-plugin-tools/job/master/34/ > Get rid of plexus-compiler-manager from tests > - > > Key: MPLUGIN-411 > URL: https://issues.apache.org/jira/browse/MPLUGIN-411 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > External dependency like plexus-compiler-manager no need to be used in tests. > The most of it tests used very old version of it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIA-665) Add anchors around FML parts
Michael Osipov created DOXIA-665: Summary: Add anchors around FML parts Key: DOXIA-665 URL: https://issues.apache.org/jira/browse/DOXIA-665 Project: Maven Doxia Issue Type: Improvement Components: Module - Fml Affects Versions: 2.0.0-M3 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0-M4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIA-666) Remove code duplication Xhtml5Sink
Michael Osipov created DOXIA-666:
Summary: Remove code duplication Xhtml5Sink
Key: DOXIA-666
URL: https://issues.apache.org/jira/browse/DOXIA-666
Project: Maven Doxia
Issue Type: Task
Components: Module - Xhtml
Affects Versions: 2.0.0-M3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.0.0-M4
{{Xhtml5Sink}} duplicates code from the parent class. That code can safely be
removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (DOXIA-599) Remove element with name attribute and replace with id in element
[
https://issues.apache.org/jira/browse/DOXIA-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned DOXIA-599:
Assignee: Michael Osipov
> Remove element with name attribute and replace with id in element
> -
>
> Key: DOXIA-599
> URL: https://issues.apache.org/jira/browse/DOXIA-599
> Project: Maven Doxia
> Issue Type: Sub-task
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Labels: intern
> Fix For: 2.0.0-M4
>
>
> *Warning*: The {{name}} attribute is obsolete. Consider putting an {{id}}
> attribute on the nearest container instead.
> From line 133, column 5; to line 133, column 53
> {{tion>↩**We}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-599) Remove element with name attribute and replace with id in element
[
https://issues.apache.org/jira/browse/DOXIA-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570298#comment-17570298
]
Michael Osipov commented on DOXIA-599:
--
Looking at the Doxia code it is not trivial to retain
{{sectionTitle()}}/{{anchor()}} logic which combining both in the Xhtml5Sink.
The sink interface is just too generic for that. I have a solution in place
which simply uses the {{id}} attribute on the anchor and that is good enough.
> Remove element with name attribute and replace with id in element
> -
>
> Key: DOXIA-599
> URL: https://issues.apache.org/jira/browse/DOXIA-599
> Project: Maven Doxia
> Issue Type: Sub-task
>Reporter: Sylwester Lachiewicz
>Priority: Minor
> Labels: intern
> Fix For: 2.0.0-M4
>
>
> *Warning*: The {{name}} attribute is obsolete. Consider putting an {{id}}
> attribute on the nearest container instead.
> From line 133, column 5; to line 133, column 53
> {{tion>↩**We}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-266) Don't create anchors behind the user's back
Michael Osipov created DOXIASITETOOLS-266:
-
Summary: Don't create anchors behind the user's back
Key: DOXIASITETOOLS-266
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-266
Project: Maven Doxia Sitetools
Issue Type: Bug
Components: Site renderer
Affects Versions: 2.0.0-M3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.0.0-M4
{{SiteRendererSink}} wraps the actual sink and intercepts all calls to section
titles. While there it automatically adds anchors not requested by the user.
This creates the following problems (non exhaustive):
* The user never requested to do so
* The output differs from direct Doxia invocation and is not documented. E.g.,
site plugin vs direct goal
* Apt format explicitly states that no anchors are generated for section titles
* Maven Reporting Impl's {{AbstractRenderer}} in {{#startSection()}} adds
anchors to the section titles which results in two anchors for the same section
title.
Stop manipulating output and make it consistent with non-site usecases and the
specs of respective formats.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1106) Improve and simplify section handling
Michael Osipov created MSHARED-1106: --- Summary: Improve and simplify section handling Key: MSHARED-1106 URL: https://issues.apache.org/jira/browse/MSHARED-1106 Project: Maven Shared Components Issue Type: Improvement Components: maven-reporting-impl Affects Versions: maven-reporting-impl-4.0.0-M2 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0-M3 The current code has following flaws: * It unnecessarily uses a switch case although it could pass the depth directly * The anchor is placed *after* the section title which mean that if a user jumps to the anchor the section title is not visible in the browser -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-plugin-tools] slawekjaranowski merged pull request #69: [MPLUGIN-393] Upgrade to JUnit 5 and @Inject annotations
slawekjaranowski merged PR #69: URL: https://github.com/apache/maven-plugin-tools/pull/69 -- 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] (MSHARED-1106) Improve and simplify section handling
[ https://issues.apache.org/jira/browse/MSHARED-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1106: Description: The current code has following flaws: * It unnecessarily uses a switch case although it could pass the depth directly * The anchor is placed *after* the section title which mean that if a user jumps to the anchor the section title is not visible in the browser Tasks: * Use sink's section title method with depth arg * Place anchor inside the section title idential to other sinks which create anchored section titles (concistency) was: The current code has following flaws: * It unnecessarily uses a switch case although it could pass the depth directly * The anchor is placed *after* the section title which mean that if a user jumps to the anchor the section title is not visible in the browser > Improve and simplify section handling > - > > Key: MSHARED-1106 > URL: https://issues.apache.org/jira/browse/MSHARED-1106 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M2 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0-M3 > > > The current code has following flaws: > * It unnecessarily uses a switch case although it could pass the depth > directly > * The anchor is placed *after* the section title which mean that if a user > jumps to the anchor the section title is not visible in the browser > Tasks: > * Use sink's section title method with depth arg > * Place anchor inside the section title idential to other sinks which create > anchored section titles (concistency) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-393) Upgrade to JUnit 5 and @Inject annotations
[ https://issues.apache.org/jira/browse/MPLUGIN-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570308#comment-17570308 ] ASF GitHub Bot commented on MPLUGIN-393: slawekjaranowski merged PR #69: URL: https://github.com/apache/maven-plugin-tools/pull/69 > Upgrade to JUnit 5 and @Inject annotations > --- > > Key: MPLUGIN-393 > URL: https://issues.apache.org/jira/browse/MPLUGIN-393 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPLUGIN-393) Upgrade to JUnit 5 and @Inject annotations
[ https://issues.apache.org/jira/browse/MPLUGIN-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPLUGIN-393. --- Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade to JUnit 5 and @Inject annotations > --- > > Key: MPLUGIN-393 > URL: https://issues.apache.org/jira/browse/MPLUGIN-393 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPLUGIN-388:
---
Fix Version/s: (was: 3.7.0)
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-410) Create implementation attribute for @Parameter as it exists for javadoc @parameter
[ https://issues.apache.org/jira/browse/MPLUGIN-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPLUGIN-410: --- Summary: Create implementation attribute for @Parameter as it exists for javadoc @parameter (was: create implementation attribute for @Parameter as it exists for javadoc @parameter) > Create implementation attribute for @Parameter as it exists for javadoc > @parameter > -- > > Key: MPLUGIN-410 > URL: https://issues.apache.org/jira/browse/MPLUGIN-410 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: maven-plugin-tools-annotations >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.7.0 > > > it exists in javadoc annotations: > https://maven.apache.org/plugin-tools/maven-plugin-tools-java/ (line 33) > that goes into plugin.xml descriptor > https://maven.apache.org/ref/3.8.6/maven-plugin-api/plugin.html (line 44) > but was forgotten in Java 5 annotations: > https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/ (line > 44) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-393) Upgrade to JUnit 5 and @Inject annotations
[ https://issues.apache.org/jira/browse/MPLUGIN-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570312#comment-17570312 ] Hudson commented on MPLUGIN-393: Build succeeded in Jenkins: Maven » Maven TLP » maven-plugin-tools » master #35 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-plugin-tools/job/master/35/ > Upgrade to JUnit 5 and @Inject annotations > --- > > Key: MPLUGIN-393 > URL: https://issues.apache.org/jira/browse/MPLUGIN-393 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
michael-o commented on code in PR #743:
URL: https://github.com/apache/maven/pull/743#discussion_r928140254
##
maven-core/src/test/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilderTest.java:
##
@@ -0,0 +1,102 @@
+package org.apache.maven.lifecycle.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to you under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+import java.lang.reflect.Field;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.apache.maven.execution.AbstractExecutionListener;
+import org.apache.maven.execution.DefaultMavenExecutionRequest;
+import org.apache.maven.execution.DefaultMavenExecutionResult;
+import org.apache.maven.execution.MavenExecutionRequest;
+import org.apache.maven.execution.MavenExecutionResult;
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.lifecycle.LifecycleExecutionException;
+import org.apache.maven.lifecycle.internal.builder.BuilderCommon;
+import
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder;
+import org.apache.maven.lifecycle.internal.stub.DefaultLifecyclesStub;
+import
org.apache.maven.lifecycle.internal.stub.LifecycleTaskSegmentCalculatorStub;
+import org.apache.maven.lifecycle.internal.stub.LoggerStub;
+import org.apache.maven.lifecycle.internal.stub.MojoExecutorStub;
+import org.apache.maven.lifecycle.internal.stub.ProjectDependencyGraphStub;
+import org.apache.maven.plugin.MojoExecution;
+import org.apache.maven.project.MavenProject;
+import org.codehaus.plexus.ContainerConfiguration;
+import org.codehaus.plexus.PlexusConstants;
+import org.codehaus.plexus.PlexusTestCase;
+import org.codehaus.plexus.logging.Logger;
+import org.junit.Test;
+
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertSame;
+
+public class LifecycleModuleBuilderTest extends PlexusTestCase
+{
+@Override
+protected void customizeContainerConfiguration( ContainerConfiguration
configuration )
+{
+configuration.setAutoWiring( true );
+configuration.setClassPathScanning( PlexusConstants.SCANNING_INDEX );
+
+}
+
+public void testCurrentProject() throws Exception
+{
+List currentProjects = new ArrayList<>();
+MojoExecutorStub mojoExecutor = new MojoExecutorStub()
+{
+@Override
+public void execute( MavenSession session, List
mojoExecutions, ProjectIndex projectIndex )
+throws LifecycleExecutionException
+{
+super.execute( session, mojoExecutions, projectIndex );
+currentProjects.add( session.getCurrentProject() );
+}
+};
+
+final DefaultMavenExecutionResult defaultMavenExecutionResult = new
DefaultMavenExecutionResult();
+MavenExecutionRequest mavenExecutionRequest = new
DefaultMavenExecutionRequest();
+mavenExecutionRequest.setExecutionListener( new
AbstractExecutionListener() );
+mavenExecutionRequest.setGoals( Arrays.asList( "clean" ) );
+mavenExecutionRequest.setDegreeOfConcurrency( 1 );
Review Comment:
This is the default value. Any specific reason to set it explicitly?
--
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-7401) Make MavenSession#getCurrentProject() using a thread local
[
https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570328#comment-17570328
]
ASF GitHub Bot commented on MNG-7401:
-
michael-o commented on code in PR #743:
URL: https://github.com/apache/maven/pull/743#discussion_r928140254
##
maven-core/src/test/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilderTest.java:
##
@@ -0,0 +1,102 @@
+package org.apache.maven.lifecycle.internal;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to you under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+import java.lang.reflect.Field;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import java.util.concurrent.atomic.AtomicReference;
+
+import org.apache.maven.execution.AbstractExecutionListener;
+import org.apache.maven.execution.DefaultMavenExecutionRequest;
+import org.apache.maven.execution.DefaultMavenExecutionResult;
+import org.apache.maven.execution.MavenExecutionRequest;
+import org.apache.maven.execution.MavenExecutionResult;
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.lifecycle.LifecycleExecutionException;
+import org.apache.maven.lifecycle.internal.builder.BuilderCommon;
+import
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder;
+import org.apache.maven.lifecycle.internal.stub.DefaultLifecyclesStub;
+import
org.apache.maven.lifecycle.internal.stub.LifecycleTaskSegmentCalculatorStub;
+import org.apache.maven.lifecycle.internal.stub.LoggerStub;
+import org.apache.maven.lifecycle.internal.stub.MojoExecutorStub;
+import org.apache.maven.lifecycle.internal.stub.ProjectDependencyGraphStub;
+import org.apache.maven.plugin.MojoExecution;
+import org.apache.maven.project.MavenProject;
+import org.codehaus.plexus.ContainerConfiguration;
+import org.codehaus.plexus.PlexusConstants;
+import org.codehaus.plexus.PlexusTestCase;
+import org.codehaus.plexus.logging.Logger;
+import org.junit.Test;
+
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertSame;
+
+public class LifecycleModuleBuilderTest extends PlexusTestCase
+{
+@Override
+protected void customizeContainerConfiguration( ContainerConfiguration
configuration )
+{
+configuration.setAutoWiring( true );
+configuration.setClassPathScanning( PlexusConstants.SCANNING_INDEX );
+
+}
+
+public void testCurrentProject() throws Exception
+{
+List currentProjects = new ArrayList<>();
+MojoExecutorStub mojoExecutor = new MojoExecutorStub()
+{
+@Override
+public void execute( MavenSession session, List
mojoExecutions, ProjectIndex projectIndex )
+throws LifecycleExecutionException
+{
+super.execute( session, mojoExecutions, projectIndex );
+currentProjects.add( session.getCurrentProject() );
+}
+};
+
+final DefaultMavenExecutionResult defaultMavenExecutionResult = new
DefaultMavenExecutionResult();
+MavenExecutionRequest mavenExecutionRequest = new
DefaultMavenExecutionRequest();
+mavenExecutionRequest.setExecutionListener( new
AbstractExecutionListener() );
+mavenExecutionRequest.setGoals( Arrays.asList( "clean" ) );
+mavenExecutionRequest.setDegreeOfConcurrency( 1 );
Review Comment:
This is the default value. Any specific reason to set it explicitly?
> Make MavenSession#getCurrentProject() using a thread local
> --
>
> Key: MNG-7401
> URL: https://issues.apache.org/jira/browse/MNG-7401
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.9.0, waiting-for-feedback
>
>
> I noticed that a session is often cloned due to change the current project
> for a while.
> As this works for everyone passing down the session, consumers of the "upper
> session" (e.g. a SessionScoped Component) would never see this if they are
> (indirectly)
[GitHub] [maven-integration-testing] michael-o commented on a diff in pull request #177: [MNG-7474] Add an IT
michael-o commented on code in PR #177:
URL:
https://github.com/apache/maven-integration-testing/pull/177#discussion_r928140402
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7474SessionScopeTest.java:
##
@@ -0,0 +1,64 @@
+package org.apache.maven.it;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7474";>MNG-7474:
+ * check that Session scope beans are actually singletons for the session.
+ */
+public class MavenITmng7474SessionScopeTest
+extends AbstractMavenIntegrationTestCase
+{
+private File projectDir;
+
+public MavenITmng7474SessionScopeTest()
+{
+super( "[3.9.0,)" );
+}
+
+@Override
+protected void setUp()
+throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7474-session-scope" );
+projectDir = new File( testDir, "project" );
+}
+
+public void testSessionScope()
+throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7474-session-scope" );
+
+Verifier verifier = newVerifier( testDir.getAbsolutePath() );
+verifier.executeGoal( "validate" );
+verifier.verifyErrorFreeLog();
+verifier.resetStreams();
+
+List logLines = verifier.loadFile( verifier.getBasedir(),
verifier.getLogFileName(), false );
Review Comment:
Why do you load them w/o any verification?
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7474SessionScopeTest.java:
##
@@ -0,0 +1,64 @@
+package org.apache.maven.it;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+/**
+ * This is a test set for https://issues.apache.org/jira/browse/MNG-7474";>MNG-7474:
+ * check that Session scope beans are actually singletons for the session.
+ */
+public class MavenITmng7474SessionScopeTest
+extends AbstractMavenIntegrationTestCase
+{
+private File projectDir;
+
+public MavenITmng7474SessionScopeTest()
+{
+super( "[3.9.0,)" );
+}
+
+@Override
+protected void setUp()
+throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7474-session-scope" );
+projectDir = new File( testDir, "project" );
+}
+
+public void testSessionScope()
+throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources( getClass(),
"/mng-7474-session-scope" );
Review Comment:
Why another extract?
--
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
[GitHub] [maven-integration-testing] michael-o commented on pull request #177: [MNG-7474] SessionScoped beans should be singletons for a given session
michael-o commented on PR #177: URL: https://github.com/apache/maven-integration-testing/pull/177#issuecomment-1193152458 Running ITs... -- 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] (MRESOURCES-286) Upgrade Maven Filtering to 3.3.0
[ https://issues.apache.org/jira/browse/MRESOURCES-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOURCES-286: -- Summary: Upgrade Maven Filtering to 3.3.0 (was: Upgrade maven-filtering to 3.3.x) > Upgrade Maven Filtering to 3.3.0 > > > Key: MRESOURCES-286 > URL: https://issues.apache.org/jira/browse/MRESOURCES-286 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: 3.3.0 > > > To address issues -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOURCES-286) Upgrade Maven Filtering to 3.3.0
[ https://issues.apache.org/jira/browse/MRESOURCES-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOURCES-286. - Assignee: Olivier Lamy Resolution: Fixed Fixed with [f76c74964e6f0a87fb19be656ac7a7d070470ba8|https://gitbox.apache.org/repos/asf?p=maven-resources-plugin.git;a=commit;h=f76c74964e6f0a87fb19be656ac7a7d070470ba8]. > Upgrade Maven Filtering to 3.3.0 > > > Key: MRESOURCES-286 > URL: https://issues.apache.org/jira/browse/MRESOURCES-286 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.3.0 > > > To address issues -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-264:
-
Fix Version/s: (was: 1.8.2)
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #178: [MRESOLVER-7] download poms in parallel
michael-o commented on code in PR #178:
URL: https://github.com/apache/maven-resolver/pull/178#discussion_r928152490
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java:
##
@@ -334,6 +370,82 @@ private void doRecurse( Args args,
DependencyProcessingContext parentContext,
}
}
+private boolean filter( DependencyProcessingContext context )
+{
+if ( context.depSelector != null &&
!context.depSelector.selectDependency( context.dependency ) )
Review Comment:
Why not compact to `return ( context.dep...)`?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java:
##
@@ -365,6 +477,64 @@ else if ( descriptorResult == DataPool.NO_DESCRIPTOR )
return descriptorResult;
}
+static class ParallelDescriptorResolver
+{
+final ExecutorService executorService;
Review Comment:
Can this resolver leverage the same executor service as for artifacts with
`aether.connector.basic.threads`? At the end it does not matter what the
connector transports, no?
See: org.eclipse.aether.connector.basic.BasicRepositoryConnector
--
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-7) Download dependency POMs in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570351#comment-17570351
]
ASF GitHub Bot commented on MRESOLVER-7:
michael-o commented on code in PR #178:
URL: https://github.com/apache/maven-resolver/pull/178#discussion_r928152490
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java:
##
@@ -334,6 +370,82 @@ private void doRecurse( Args args,
DependencyProcessingContext parentContext,
}
}
+private boolean filter( DependencyProcessingContext context )
+{
+if ( context.depSelector != null &&
!context.depSelector.selectDependency( context.dependency ) )
Review Comment:
Why not compact to `return ( context.dep...)`?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java:
##
@@ -365,6 +477,64 @@ else if ( descriptorResult == DataPool.NO_DESCRIPTOR )
return descriptorResult;
}
+static class ParallelDescriptorResolver
+{
+final ExecutorService executorService;
Review Comment:
Can this resolver leverage the same executor service as for artifacts with
`aether.connector.basic.threads`? At the end it does not matter what the
connector transports, no?
See: org.eclipse.aether.connector.basic.BasicRepositoryConnector
> Download dependency POMs in parallel
>
>
> Key: MRESOLVER-7
> URL: https://issues.apache.org/jira/browse/MRESOLVER-7
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: Aether 1.0.2
>Reporter: Harald Wellmann
>Priority: Major
> Attachments: resolver.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Background
> When building a project with dependencies not yet available in the local
> repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the
> dependency POMs _sequentially_ and then proceeds downloading the dependency
> JARs with up to 5 threads _in parallel_.
> Due to this, when first building a project with a large number of
> dependencies, downloading a large number of small POMs may take a lot longer
> than downloading the much larger JARs, or even longer than building the
> project itself, especially when a repository manager is used which increases
> the download latency.
> h3. Enhancement
> Download POMs of (transitive) dependencies in parallel to significantly speed
> up initial builds of large projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-251) Upgrade Redisson to 3.17.5
[ https://issues.apache.org/jira/browse/MRESOLVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-251: - Summary: Upgrade Redisson to 3.17.5 (was: Upgrade Redisson to 3.17.1) > Upgrade Redisson to 3.17.5 > -- > > Key: MRESOLVER-251 > URL: https://issues.apache.org/jira/browse/MRESOLVER-251 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: resolver-next > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-251) Upgrade Redisson to 3.17.5
[ https://issues.apache.org/jira/browse/MRESOLVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-251: - Fix Version/s: 1.8.2 (was: resolver-next) > Upgrade Redisson to 3.17.5 > -- > > Key: MRESOLVER-251 > URL: https://issues.apache.org/jira/browse/MRESOLVER-251 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MRESOLVER-246:
Assignee: Tamás Cservenák
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Assignee: Tamás Cservenák
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-246:
-
Fix Version/s: 1.8.2
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.2
>
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570353#comment-17570353
]
Michael Osipov commented on MRESOLVER-246:
--
I believe that this is solved by MRESOLVER-241.
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.2
>
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570353#comment-17570353
]
Michael Osipov edited comment on MRESOLVER-246 at 7/23/22 7:04 PM:
---
I believe that this is solved by MRESOLVER-265.
was (Author: michael-o):
I believe that this is solved by MRESOLVER-241.
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.2
>
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570354#comment-17570354
]
Michael Osipov commented on MRESOLVER-224:
--
Still waiting...
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-266) Simplify adapter creation and align configuration for it
[ https://issues.apache.org/jira/browse/MRESOLVER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-266: - Fix Version/s: (was: 1.8.2) > Simplify adapter creation and align configuration for it > > > Key: MRESOLVER-266 > URL: https://issues.apache.org/jira/browse/MRESOLVER-266 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamás Cservenák >Priority: Major > > Rework how named lock factory adapter is created, it is the ONLY bit reaching > directly to Java System Properties instead to rely on session config > properties. This makes it impossible to control from Maven for example (as it > is "too late"). > Proposed changes: > * adapter should be created based on session config properties, not Java > system properties > * adapter should be stored within session > * adapter creation should be vastly simplified (currently we have 4 involved > class: selectors and default sync context) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] michael-o commented on pull request #177: [MNG-7474] SessionScoped beans should be singletons for a given session
michael-o commented on PR #177: URL: https://github.com/apache/maven-integration-testing/pull/177#issuecomment-1193178973 After version bump of MRESOURCES all tests pass for me on Windows 10 and FreeBSD 12. Waiting for comment answers. -- 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
[GitHub] [maven] Yougoss commented on a diff in pull request #768: [MNG-7509] - Huge memory cost when parent pom widely used in a big project for dependencyManagement for maven-3.9.x
Yougoss commented on code in PR #768: URL: https://github.com/apache/maven/pull/768#discussion_r928158694 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: done -- 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-7509) Huge memory cost when parent pom widely used in a big project for dependencyManagement
[ https://issues.apache.org/jira/browse/MNG-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570362#comment-17570362 ] ASF GitHub Bot commented on MNG-7509: - Yougoss commented on code in PR #768: URL: https://github.com/apache/maven/pull/768#discussion_r928158694 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: done > Huge memory cost when parent pom widely used in a big project for > dependencyManagement > -- > > Key: MNG-7509 > URL: https://issues.apache.org/jira/browse/MNG-7509 > Project: Maven > Issue Type: Improvement > Components: Performance >Reporter: Xiong Luyao >Priority: Critical > Attachments: image-2022-07-09-09-37-53-823.png, > image-2022-07-09-09-38-26-354.png, image-2022-07-09-10-27-12-668.png, > image-2022-07-09-10-27-56-437.png, image-2022-07-09-10-28-05-706.png, > image-2022-07-09-10-28-22-864.png, image-2022-07-09-10-28-35-341.png, > image-2022-07-09-10-28-40-612.png, image-2022-07-09-10-29-04-045.png, > image-2022-07-09-10-29-15-822.png, image-2022-07-09-10-29-21-991.png, > image-2022-07-09-10-29-46-216.png, image-2022-07-09-10-29-51-456.png > > > When maven try to resolve dependency relationship, it will create many > instances of dependency / artifact, even the dependency/artifact content is > totally same, but just in different pom models. It cost huge memory if there > is a parent pom with dependencyManagement which managed a lot of > dependencies, and this parent pom are implemented by many project libraries. > (libraries_count * managedDependency_count) dependency instances will be > created. For example, if there are 3000 libraries, and all the library > introduce same parent pom which managed 3000 dependencies version. There will > be 3000*3000 =9,000,000 dependency instances will be created. But most of > them are same, in fact, we only need one instance for each dependency in > parent pom (3000 dependency instances). > > I'm from eBay, and here is a real case in enterprise level project. We have > about 3000 business domain libraries, there are dependency relationship > between them. We need to build all libraries in one release to keep all the > libraries in same release are based on same code. So we used a parent pom as > a central management to manage all the version for a release, and introduced > by those libraries. As below picture, when the release start, it will > calculate and start with the library which doesn't depend on others, then > start the library which dependency libraries are already built. Keep this > process until all libraries are built. > With current maven resolve logic, it costs huge memory in above ways to built > libraries. And even the libraries have been released, if the project which > contains a lot of above libraries, it also cost huge memory when building > project. > So current now, we have to specify version in each library pom files instead > of using parent pom. We think we can make some enhancement for this case. > > !image-2022-07-09-09-37-53-823.png|width=493,height=226! > > Here is a thread dump when building a real project which depends on about > 1000 above libraries. The top 5 objects are all related to > org.eclipse.aether.graph.Dependency. > !image-2022-07-09-09-38-26-354.png|width=510,height=199! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] Yougoss commented on a diff in pull request #764: [MNG-7509] - Huge memory cost when parent pom widely used in a big project for dependencyManagement for 3.8.x
Yougoss commented on code in PR #764: URL: https://github.com/apache/maven/pull/764#discussion_r928158716 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: done -- 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-7509) Huge memory cost when parent pom widely used in a big project for dependencyManagement
[ https://issues.apache.org/jira/browse/MNG-7509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570363#comment-17570363 ] ASF GitHub Bot commented on MNG-7509: - Yougoss commented on code in PR #764: URL: https://github.com/apache/maven/pull/764#discussion_r928158716 ## maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegateTest.java: ## @@ -0,0 +1,79 @@ +package org.apache.maven.repository.internal; + +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.Model; +import org.eclipse.aether.artifact.DefaultArtifact; +import org.eclipse.aether.resolution.ArtifactDescriptorRequest; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; + Review Comment: done > Huge memory cost when parent pom widely used in a big project for > dependencyManagement > -- > > Key: MNG-7509 > URL: https://issues.apache.org/jira/browse/MNG-7509 > Project: Maven > Issue Type: Improvement > Components: Performance >Reporter: Xiong Luyao >Priority: Critical > Attachments: image-2022-07-09-09-37-53-823.png, > image-2022-07-09-09-38-26-354.png, image-2022-07-09-10-27-12-668.png, > image-2022-07-09-10-27-56-437.png, image-2022-07-09-10-28-05-706.png, > image-2022-07-09-10-28-22-864.png, image-2022-07-09-10-28-35-341.png, > image-2022-07-09-10-28-40-612.png, image-2022-07-09-10-29-04-045.png, > image-2022-07-09-10-29-15-822.png, image-2022-07-09-10-29-21-991.png, > image-2022-07-09-10-29-46-216.png, image-2022-07-09-10-29-51-456.png > > > When maven try to resolve dependency relationship, it will create many > instances of dependency / artifact, even the dependency/artifact content is > totally same, but just in different pom models. It cost huge memory if there > is a parent pom with dependencyManagement which managed a lot of > dependencies, and this parent pom are implemented by many project libraries. > (libraries_count * managedDependency_count) dependency instances will be > created. For example, if there are 3000 libraries, and all the library > introduce same parent pom which managed 3000 dependencies version. There will > be 3000*3000 =9,000,000 dependency instances will be created. But most of > them are same, in fact, we only need one instance for each dependency in > parent pom (3000 dependency instances). > > I'm from eBay, and here is a real case in enterprise level project. We have > about 3000 business domain libraries, there are dependency relationship > between them. We need to build all libraries in one release to keep all the > libraries in same release are based on same code. So we used a parent pom as > a central management to manage all the version for a release, and introduced > by those libraries. As below picture, when the release start, it will > calculate and start with the library which doesn't depend on others, then > start the library which dependency libraries are already built. Keep this > process until all libraries are built. > With current maven resolve logic, it costs huge memory in above ways to built > libraries. And even the libraries have been released, if the project which > contains a lot of above libraries, it also cost huge memory when building > project. > So current now, we have to specify version in each library pom files instead > of using parent pom. We think we can make some enhancement for this case. > > !image-2022-07-09-09-37-53-823.png|width=493,height=226! > > Here is a thread dump when building a real project which depends on about > 1000 above libraries. The top 5 objects are all related to > org.eclipse.aether.graph.Dependency. > !image-2022-07-09-09-38-26-354.png|width=510,height=199! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-scm] kwin commented on pull request #144: [SCM-925] Implement RemoveCommand in maven-scm-provider-jgit
kwin commented on PR #144: URL: https://github.com/apache/maven-scm/pull/144#issuecomment-1193181758 @michael-o You find my refinement in #156. -- 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] (SCM-925) Implement RemoveCommand in maven-scm-provider-jgit
[ https://issues.apache.org/jira/browse/SCM-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570366#comment-17570366 ] ASF GitHub Bot commented on SCM-925: kwin commented on PR #144: URL: https://github.com/apache/maven-scm/pull/144#issuecomment-1193181758 @michael-o You find my refinement in #156. > Implement RemoveCommand in maven-scm-provider-jgit > -- > > Key: SCM-925 > URL: https://issues.apache.org/jira/browse/SCM-925 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-jgit >Affects Versions: 1.11.2 >Reporter: Georg Tsakumagos >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M3 > > Attachments: maven-scm-provider-jgit.log > > Time Spent: 10m > Remaining Estimate: 0h > > The git scm plugins differs in support for the scm command _remove_. This > breaks the goal _prepare-with-pom_ of the _maven-release-plugin_ using the > _maven-scm-provider-jgit_. The method is not fully implemented and throws an > UnsupportedOperationException. > Referring to the ["Maven SCM Providers > Matrix"|https://maven.apache.org/scm/matrix.html] this feature is documented > as supported and should be implemented in the _jgit_ provider like in > maven-scm-provider-gitexe. > > ||Variant||remove supported||Source|| > |maven-scm-provider-gitexe|(/)|[Github - GitExeScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java#L97]| > |maven-scm-provider-jgit|(x)|[Github - JGitScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/JGitScmProvider.java#L113]| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-scm] kwin commented on pull request #156: [SCM-925] Implement RemoveCommand in maven-scm-provider-jgit with TCK test for all providers
kwin commented on PR #156: URL: https://github.com/apache/maven-scm/pull/156#issuecomment-1193181846 @michael-o Any idea why the HG provider fails for the remove test? I have no experience with HG at all. -- 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] (SCM-925) Implement RemoveCommand in maven-scm-provider-jgit
[ https://issues.apache.org/jira/browse/SCM-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570367#comment-17570367 ] ASF GitHub Bot commented on SCM-925: kwin commented on PR #156: URL: https://github.com/apache/maven-scm/pull/156#issuecomment-1193181846 @michael-o Any idea why the HG provider fails for the remove test? I have no experience with HG at all. > Implement RemoveCommand in maven-scm-provider-jgit > -- > > Key: SCM-925 > URL: https://issues.apache.org/jira/browse/SCM-925 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-jgit >Affects Versions: 1.11.2 >Reporter: Georg Tsakumagos >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M3 > > Attachments: maven-scm-provider-jgit.log > > Time Spent: 10m > Remaining Estimate: 0h > > The git scm plugins differs in support for the scm command _remove_. This > breaks the goal _prepare-with-pom_ of the _maven-release-plugin_ using the > _maven-scm-provider-jgit_. The method is not fully implemented and throws an > UnsupportedOperationException. > Referring to the ["Maven SCM Providers > Matrix"|https://maven.apache.org/scm/matrix.html] this feature is documented > as supported and should be implemented in the _jgit_ provider like in > maven-scm-provider-gitexe. > > ||Variant||remove supported||Source|| > |maven-scm-provider-gitexe|(/)|[Github - GitExeScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java#L97]| > |maven-scm-provider-jgit|(x)|[Github - JGitScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/JGitScmProvider.java#L113]| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-scm] michael-o commented on pull request #156: [SCM-925] Implement RemoveCommand in maven-scm-provider-jgit with TCK test for all providers
michael-o commented on PR #156: URL: https://github.com/apache/maven-scm/pull/156#issuecomment-1193183417 No idea, I have other problems with Mercurial as well. Run master w/o your patch and see whether `tck-hg` passes for you. Not for me. -- 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] (SCM-925) Implement RemoveCommand in maven-scm-provider-jgit
[ https://issues.apache.org/jira/browse/SCM-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570369#comment-17570369 ] ASF GitHub Bot commented on SCM-925: michael-o commented on PR #156: URL: https://github.com/apache/maven-scm/pull/156#issuecomment-1193183417 No idea, I have other problems with Mercurial as well. Run master w/o your patch and see whether `tck-hg` passes for you. Not for me. > Implement RemoveCommand in maven-scm-provider-jgit > -- > > Key: SCM-925 > URL: https://issues.apache.org/jira/browse/SCM-925 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-jgit >Affects Versions: 1.11.2 >Reporter: Georg Tsakumagos >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M3 > > Attachments: maven-scm-provider-jgit.log > > Time Spent: 10m > Remaining Estimate: 0h > > The git scm plugins differs in support for the scm command _remove_. This > breaks the goal _prepare-with-pom_ of the _maven-release-plugin_ using the > _maven-scm-provider-jgit_. The method is not fully implemented and throws an > UnsupportedOperationException. > Referring to the ["Maven SCM Providers > Matrix"|https://maven.apache.org/scm/matrix.html] this feature is documented > as supported and should be implemented in the _jgit_ provider like in > maven-scm-provider-gitexe. > > ||Variant||remove supported||Source|| > |maven-scm-provider-gitexe|(/)|[Github - GitExeScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java#L97]| > |maven-scm-provider-jgit|(x)|[Github - JGitScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/JGitScmProvider.java#L113]| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-251) Upgrade Redisson to 3.17.5
[ https://issues.apache.org/jira/browse/MRESOLVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-251. Resolution: Fixed Fixed with [802b50df5d9b7e3936f98b71496ece88da62f223|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=802b50df5d9b7e3936f98b71496ece88da62f223]. > Upgrade Redisson to 3.17.5 > -- > > Key: MRESOLVER-251 > URL: https://issues.apache.org/jira/browse/MRESOLVER-251 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-251) Upgrade Redisson to 3.17.5
[ https://issues.apache.org/jira/browse/MRESOLVER-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570371#comment-17570371 ] Hudson commented on MRESOLVER-251: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #42 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/42/ > Upgrade Redisson to 3.17.5 > -- > > Key: MRESOLVER-251 > URL: https://issues.apache.org/jira/browse/MRESOLVER-251 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7520) Simply integration of Redisson and Hazelcast for Maven Resolver
Michael Osipov created MNG-7520:
---
Summary: Simply integration of Redisson and Hazelcast for Maven
Resolver
Key: MNG-7520
URL: https://issues.apache.org/jira/browse/MNG-7520
Project: Maven
Issue Type: Improvement
Components: Artifacts and Repositories, Dependencies
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
Currently, to integrate Redisson or Hazelcast into Maven for distributed
locking you need to create directories and modify {{m2.conf}}. We can make life
easier by pre-creating them in the distribution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7520) Simplify integration of Redisson and Hazelcast for Maven Resolver
[
https://issues.apache.org/jira/browse/MNG-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7520:
Summary: Simplify integration of Redisson and Hazelcast for Maven Resolver
(was: Simply integration of Redisson and Hazelcast for Maven Resolver)
> Simplify integration of Redisson and Hazelcast for Maven Resolver
> -
>
> Key: MNG-7520
> URL: https://issues.apache.org/jira/browse/MNG-7520
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, Dependencies
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently, to integrate Redisson or Hazelcast into Maven for distributed
> locking you need to create directories and modify {{m2.conf}}. We can make
> life easier by pre-creating them in the distribution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o opened a new pull request, #776: [MNG-7520] Simplify integration of Redisson and Hazelcast for Maven R…
michael-o opened a new pull request, #776: URL: https://github.com/apache/maven/pull/776 …esolver This closes #776 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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-7520) Simplify integration of Redisson and Hazelcast for Maven Resolver
[
https://issues.apache.org/jira/browse/MNG-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570375#comment-17570375
]
ASF GitHub Bot commented on MNG-7520:
-
michael-o opened a new pull request, #776:
URL: https://github.com/apache/maven/pull/776
…esolver
This closes #776
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` with the appropriate JIRA issue. Best practice is to
use the JIRA issue
title in the pull request title and in the first line of the commit
message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [ ] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Simplify integration of Redisson and Hazelcast for Maven Resolver
> -
>
> Key: MNG-7520
> URL: https://issues.apache.org/jira/browse/MNG-7520
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, Dependencies
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently, to integrate Redisson or Hazelcast into Maven for distributed
> locking you need to create directories and modify {{m2.conf}}. We can make
> life easier by pre-creating them in the distribution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7151) Upgrade Maven Resolver to 1.7.0
[ https://issues.apache.org/jira/browse/MNG-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570377#comment-17570377 ] Hudson commented on MNG-7151: - Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.8.x-resolver-1.8.x #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x-resolver-1.8.x/2/ > Upgrade Maven Resolver to 1.7.0 > --- > > Key: MNG-7151 > URL: https://issues.apache.org/jira/browse/MNG-7151 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.8.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0-alpha-1, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570376#comment-17570376 ] Hudson commented on MNG-6399: - Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.8.x-resolver-1.8.x #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x-resolver-1.8.x/2/ > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7499) Upgrade Maven Resolver to 1.8.1
[ https://issues.apache.org/jira/browse/MNG-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570378#comment-17570378 ] Hudson commented on MNG-7499: - Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.8.x-resolver-1.8.x #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x-resolver-1.8.x/2/ > Upgrade Maven Resolver to 1.8.1 > --- > > Key: MNG-7499 > URL: https://issues.apache.org/jira/browse/MNG-7499 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-485) Incorrect internal string format in generated package-info.class files on Windows
[
https://issues.apache.org/jira/browse/MCOMPILER-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570379#comment-17570379
]
Hudson commented on MCOMPILER-485:
--
Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.8.x-resolver-1.8.x
#2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x-resolver-1.8.x/2/
> Incorrect internal string format in generated package-info.class files on
> Windows
> -
>
> Key: MCOMPILER-485
> URL: https://issues.apache.org/jira/browse/MCOMPILER-485
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
> Environment: Windows, or any operating system with a file separator
> character other than a forward slash
>Reporter: Daniel Widdis
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.10.1
>
>
> In 3.10.0, a new feature to generate package-info classes was added in
> [[MCOMPILER-205] |https://github.com/apache/maven-compiler-plugin/pull/88]
> Unfortunately, the binary class file is incorrectly generated using Java's
> file toString() which uses a platform dependent file separator character: on
> Windows, these Strings contain a backslash. See [this
> line|https://github.com/gnodet/maven-compiler-plugin/blob/8521ef8fdd12cc0b85c1ace17114ed3d3ffd0b0c/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1356]
> which passes the platform-dependent file name (minus the root path and .java
> extension) to the ClassWriter.
> The Java class file specification (4.2.1) specifies the internal format: "In
> this internal form, the ASCII periods (.) that normally separate the
> identifiers which make up the binary name are replaced by ASCII forward
> slashes (/)."
> This invalid class file format causes problems in downstream plugins, e.g.,
> * The bnd-maven-plugin fails with an error: Classes found in the wrong
> directory:
> \{oshi/jna/platform/unix/package-info.class=oshi\jna\platform\unix\package-info
> ... (and hundreds more) ... }
> * The JDK's
> [classFileParser|https://github.com/openjdk/jdk17/blob/74007890bb9a3fa3a65683a3f480e399f2b1a0b6/src/hotspot/share/classfile/classFileParser.cpp#L5797]
> will throw java.lang.NoClassDefFoundError:
> com\puppycrawl\tools\checkstyle\ant\package-info (wrong name:
> com/puppycrawl/tools/checkstyle/ant/package-info
> Steps to reproduce:
> # Perform a build on any Windows machine using maven-compiler-plugin 3.10.0
> # Inspect any of the generated package-info.class files in target/classes
> using a text editor
> Expected behavior:
> Internal strings representing package names use forward slashes
> Observed behavior:
> Internal strings representing package names use backward slashes
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #776: [MNG-7520] Simplify integration of Redisson and Hazelcast for Maven R…
michael-o commented on PR #776: URL: https://github.com/apache/maven/pull/776#issuecomment-1193197452 @jebeaudet have a look -- 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-7520) Simplify integration of Redisson and Hazelcast for Maven Resolver
[
https://issues.apache.org/jira/browse/MNG-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570381#comment-17570381
]
ASF GitHub Bot commented on MNG-7520:
-
michael-o commented on PR #776:
URL: https://github.com/apache/maven/pull/776#issuecomment-1193197452
@jebeaudet have a look
> Simplify integration of Redisson and Hazelcast for Maven Resolver
> -
>
> Key: MNG-7520
> URL: https://issues.apache.org/jira/browse/MNG-7520
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, Dependencies
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently, to integrate Redisson or Hazelcast into Maven for distributed
> locking you need to create directories and modify {{m2.conf}}. We can make
> life easier by pre-creating them in the distribution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #765: Experiment: warn on ancient plugin
michael-o commented on code in PR #765:
URL: https://github.com/apache/maven/pull/765#discussion_r928173326
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java:
##
@@ -419,6 +424,29 @@ private void createPluginRealm( PluginDescriptor
pluginDescriptor, MavenSession
pluginDescriptor.setClassRealm( pluginRealm );
pluginDescriptor.setArtifacts( pluginArtifacts );
+
+try
+{
+GenericVersionScheme versionScheme = new GenericVersionScheme();
+Version minimumVersion = versionScheme.parseVersion( "3.1.0" );
Review Comment:
Would it make sense to make is static final to avoid constant parsing?
--
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
[GitHub] [maven-doxia] olamy commented on pull request #97: add release drafter configuration
olamy commented on PR #97: URL: https://github.com/apache/maven-doxia/pull/97#issuecomment-1193209292 > -0 IMHO, doing this for ASF project is wrong as: > > * issues and release notes are in JIRA, JIRA is source of truth > * release drafter just adds another MANUAL step in already overly manual release process > * unsure about the quality of release notes (see Plexus containers 2.1.1 release notes done by drafter: contains TWO items, while things like QDox are not even mentioned) please provide a link as I'm not quite sure what are you talking about with plexus-containers? If you mean https://github.com/codehaus-plexus/plexus-containers. As far I can release-drafter is not used. By the way release-drafter generate changelog entries only from PRs merge after the last release of a repository. So it means: - if no manual release has been created with the last tag before using release-drafter the content can be confusing - changelog entries are generated only from PRs. So if nothing is generated for direct push to `master` branch, I guess if people push directly to `master` it probably means people thinks it's not important enough to reviewed or to be checked by some CI builds. I just wanted to improve user experience as when looking at https://maven.apache.org/doxia/ it's not really obvious to find some changelog content for a user. Anyway I'm closing it. -- 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
[GitHub] [maven-doxia] olamy closed pull request #97: add release drafter configuration
olamy closed pull request #97: add release drafter configuration URL: https://github.com/apache/maven-doxia/pull/97 -- 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
