[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735982#comment-17735982
 ] 

ASF GitHub Bot commented on MNG-7818:
-

xstefank commented on code in PR #1178:
URL: https://github.com/apache/maven/pull/1178#discussion_r1238029877


##
pom.xml:
##
@@ -525,20 +526,20 @@ under the License.
   
 org.hamcrest
 hamcrest
-2.2
+${hamcrestVersion}
+test
+  
+  
+org.hamcrest
+hamcrest-core
+${hamcrestVersion}
 test
   
   
 junit
 junit
 ${junitVersion}
 test
-

Review Comment:
   Shouldn't you actually keep the exclusion to not pull older version of 
hamcrest that conflicts with the one you defined on the top level?





> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at 

[GitHub] [maven] xstefank commented on a diff in pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4

2023-06-21 Thread via GitHub


xstefank commented on code in PR #1178:
URL: https://github.com/apache/maven/pull/1178#discussion_r1238029877


##
pom.xml:
##
@@ -525,20 +526,20 @@ under the License.
   
 org.hamcrest
 hamcrest
-2.2
+${hamcrestVersion}
+test
+  
+  
+org.hamcrest
+hamcrest-core
+${hamcrestVersion}
 test
   
   
 junit
 junit
 ${junitVersion}
 test
-

Review Comment:
   Shouldn't you actually keep the exclusion to not pull older version of 
hamcrest that conflicts with the one you defined on the top level?



-- 
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] (MDEP-875) Regression: list-repositories may produce NPE

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735975#comment-17735975
 ] 

ASF GitHub Bot commented on MDEP-875:
-

rosti-il commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1237970404


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   Done





> Regression: list-repositories may produce NPE
> -
>
> Key: MDEP-875
> URL: https://issues.apache.org/jira/browse/MDEP-875
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: list-repositories
>Affects Versions: 3.6.0
>Reporter: Rostislav Krasny
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Running the *{{mvn 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories}}* 
> command on a projects that has no repository with mirror or only repositories 
> with mirrors fails with an NPE like in the following example:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> (default-cli) on project d
> emo: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> failed: Cannot invoke
> "java.util.Collection.forEach(java.util.function.Consumer)" because 
> "remoteProjectRepositories" is null -> [Help 1]
> The "project demo" is a simple default project made by 
> https://start.spring.io/
> This regression was introduced by fix of MDEP-853 and exists only in the 
> {{3.6.0}} version of the plugin.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-dependency-plugin] rosti-il commented on a diff in pull request #328: MDEP-875 prevent possible NPE

2023-06-21 Thread via GitHub


rosti-il commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1237970404


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

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] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735955#comment-17735955
 ] 

ASF GitHub Bot commented on SUREFIRE-2182:
--

kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237936661


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+.debug("Using fork starter with configuration "

Review Comment:
   Any suggestions?





> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-surefire] kwin commented on a diff in pull request #665: [SUREFIRE-2182] Log starter implementation on DEBUG level

2023-06-21 Thread via GitHub


kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237936661


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+.debug("Using fork starter with configuration "

Review Comment:
   Any suggestions?



-- 
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-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735953#comment-17735953
 ] 

ASF GitHub Bot commented on MNG-7818:
-

lprimak commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1601942326

   Test failures are the "locking" issues, not sure how to clean maven repo in 
GH actions :(




> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] lprimak commented on pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4

2023-06-21 Thread via GitHub


lprimak commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1601942326

   Test failures are the "locking" issues, not sure how to clean maven repo in 
GH actions :(


-- 
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-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread Lenny Primak (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735949#comment-17735949
 ] 

Lenny Primak commented on MNG-7818:
---

Fixed!

> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice

2023-06-21 Thread Michael Osipov (Jira)


 [ 
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MSHARED-1275:

Description: The mentioned method called twice for standalone *and* Maven 
Site Plugin use case in 
{{org.apache.maven.reporting.AbstractMavenReport.generate(Sink, SinkFactory, 
Locale)}} also both uses cases make sure that {{canGenerateReport()}} is 
invoked _before_ {{generate()}} is invoked. This is clearly redudant and can 
incur a performance overhead.  (was: The mentioned method called twice for 
standalone **and** Maven Site Plugin use case in 
{{org.apache.maven.reporting.AbstractMavenReport.generate(Sink, SinkFactory, 
Locale)}} also both uses cases make sure that {{canGenerateReport()}} is 
invoked *before* {{generate()}} is invoked. This is clearly redudant and can 
incur a performance overhead.)

> MavenReport#canGenerateReport() is invoked twice
> 
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use 
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink, 
> SinkFactory, Locale)}} also both uses cases make sure that 
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This 
> is clearly redudant and can incur a performance overhead.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735909#comment-17735909
 ] 

ASF GitHub Bot commented on SUREFIRE-2182:
--

michael-o commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237743912


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+.debug("Using fork starter with configuration "

Review Comment:
   The statement is a bit misleading. It does not print the configuration, but 
only the configuration class (name), no?





> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-surefire] michael-o commented on a diff in pull request #665: [SUREFIRE-2182] Log starter implementation on DEBUG level

2023-06-21 Thread via GitHub


michael-o commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237743912


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+.debug("Using fork starter with configuration "

Review Comment:
   The statement is a bit misleading. It does not print the configuration, but 
only the configuration class (name), no?



-- 
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] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735903#comment-17735903
 ] 

ASF GitHub Bot commented on MSHARED-1275:
-

michael-o opened a new pull request, #21:
URL: https://github.com/apache/maven-reporting-impl/pull/21

   This closes #21




> MavenReport#canGenerateReport() is invoked twice
> 
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone **and** Maven Site Plugin 
> use case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink, 
> SinkFactory, Locale)}} also both uses cases make sure that 
> {{canGenerateReport()}} is invoked *before* {{generate()}} is invoked. This 
> is clearly redudant and can incur a performance overhead.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice

2023-06-21 Thread Michael Osipov (Jira)
Michael Osipov created MSHARED-1275:
---

 Summary: MavenReport#canGenerateReport() is invoked twice
 Key: MSHARED-1275
 URL: https://issues.apache.org/jira/browse/MSHARED-1275
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-reporting-impl
Affects Versions: maven-reporting-impl-4.0.0-M8
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: maven-reporting-impl-4.0.0-M9


The mentioned method called twice for standalone **and** Maven Site Plugin use 
case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink, 
SinkFactory, Locale)}} also both uses cases make sure that 
{{canGenerateReport()}} is invoked *before* {{generate()}} is invoked. This is 
clearly redudant and can incur a performance overhead.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception

2023-06-21 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735900#comment-17735900
 ] 

Michael Osipov commented on MSHARED-1032:
-

[~bmarwell], you are right. It is indeed called twice for standalone AND Maven 
Site Plugin use case in 
{{org.apache.maven.reporting.AbstractMavenReport.generate(Sink, SinkFactory, 
Locale)}} also both uses cases make sure that {{canGenerateReport()}} is 
invoked before {{generate()}} is invoked. This is clearly redudant an can incur 
a performance overhead. I will create a new issue and provide a PR.

As for the actual request: There are two spots which are subject to the call, I 
think we can add this exception, I have already found a suitable usecase, but 
need to check how the system behavior since the signature has changed.

> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
>  Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in 
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
>  implements a method [{{canGenerateReport()}} from 
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}} 
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because 
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot 
> be wrapped. However, the {{IOException}} from that method is useless anyway, 
> because it is never declared in any methods it calls.
> Therefore please consider:
>  * Declaring any Exception on {{canGenerateReport()}}
>  * Removing the declared {{IOException}} in PlexusUtils ([PR 
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and 
> Maven-Utils (issue: tbd).
> Thanks!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735892#comment-17735892
 ] 

ASF GitHub Bot commented on MNG-7818:
-

lprimak commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1601655201

   Oh I can fix that :)




> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] lprimak commented on pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4

2023-06-21 Thread via GitHub


lprimak commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1601655201

   Oh I can fix that :)


-- 
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] dependabot[bot] opened a new pull request, #172: Bump xalan from 2.7.2 to 2.7.3 in /doxia-modules/doxia-module-fml

2023-06-21 Thread via GitHub


dependabot[bot] opened a new pull request, #172:
URL: https://github.com/apache/maven-doxia/pull/172

   Bumps xalan from 2.7.2 to 2.7.3.
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=xalan:xalan=maven=2.7.2=2.7.3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   You can disable automated security fix PRs for this repo from the [Security 
Alerts page](https://github.com/apache/maven-doxia/network/alerts).
   
   


-- 
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] dependabot[bot] opened a new pull request, #171: Bump xalan from 2.7.2 to 2.7.3 in /doxia-modules/doxia-module-xdoc

2023-06-21 Thread via GitHub


dependabot[bot] opened a new pull request, #171:
URL: https://github.com/apache/maven-doxia/pull/171

   Bumps xalan from 2.7.2 to 2.7.3.
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=xalan:xalan=maven=2.7.2=2.7.3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   You can disable automated security fix PRs for this repo from the [Security 
Alerts page](https://github.com/apache/maven-doxia/network/alerts).
   
   


-- 
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] [Moved] (MSKINS-229) Inconsistent anchors between toc macro and headers

2023-06-21 Thread Michael Osipov (Jira)


 [ 
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov moved DOXIA-696 to MSKINS-229:
-

Fix Version/s: wontfix-candidate
   (was: wontfix-candidate)
  Key: MSKINS-229  (was: DOXIA-696)
  Project: Maven Skins  (was: Maven Doxia)

> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
>  Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In markdown document add:
> {code:java}
> 
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (MSKINS-229) Inconsistent anchors between toc macro and headers

2023-06-21 Thread Michael Osipov (Jira)


 [ 
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MSKINS-229:
--
Component/s: Fluido Skin

> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In markdown document add:
> {code:java}
> 
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735889#comment-17735889
 ] 

ASF GitHub Bot commented on SUREFIRE-2182:
--

kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237540052


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()

Review Comment:
   First https://issues.apache.org/jira/browse/SUREFIRE-2183 needs 
clarification, because for me the newly added line is not logged when using 
{{mvn -X}}. But it is logged if placed outside the guard in line 1183 (both 
with the same level debug).





> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-surefire] kwin commented on a diff in pull request #665: [SUREFIRE-2182] Log starter implementation on DEBUG level

2023-06-21 Thread via GitHub


kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237540052


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()

Review Comment:
   First https://issues.apache.org/jira/browse/SUREFIRE-2183 needs 
clarification, because for me the newly added line is not logged when using 
{{mvn -X}}. But it is logged if placed outside the guard in line 1183 (both 
with the same level debug).



-- 
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-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735888#comment-17735888
 ] 

ASF GitHub Bot commented on MNG-7818:
-

cstamas commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1601604963

   Nope, this result in "mixed" dependencies: excerpt from maven-core dep tree:
   ```
   ...
   [INFO] +- org.hamcrest:hamcrest:jar:2.2:test
   [INFO] \- junit:junit:jar:4.13.2:test
   [INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test
   ```




> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] cstamas commented on pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4

2023-06-21 Thread via GitHub


cstamas commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1601604963

   Nope, this result in "mixed" dependencies: excerpt from maven-core dep tree:
   ```
   ...
   [INFO] +- org.hamcrest:hamcrest:jar:2.2:test
   [INFO] \- junit:junit:jar:4.13.2:test
   [INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test
   ```


-- 
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] (SUREFIRE-2183) AbstractSurefireLogger.getConsoleLogger().isDebugEnabled() returns false when mvn is executed with "-X"

2023-06-21 Thread Konrad Windszus (Jira)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed SUREFIRE-2183.
-
Resolution: Invalid

This is just not true. I can also no longer reproduce. Don't know what happened 
before.

> AbstractSurefireLogger.getConsoleLogger().isDebugEnabled() returns false when 
> mvn is executed with "-X"
> ---
>
> Key: SUREFIRE-2183
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2183
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: process forking
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite the fact that running {{mvn}} with option {{-X}} is supposed to turn 
> on all debug statements the logger returned by 
> https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L888
>   does still return {{false}} for {{isDebugEnabled()}}, therefore logging 
> statements like 
> https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1183
>  are not emitted when {{-X}} or {{--debug}} are set.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work

2023-06-21 Thread Ben Tatham (Jira)


[ 
https://issues.apache.org/jira/browse/MBUILDCACHE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735871#comment-17735871
 ] 

Ben Tatham commented on MBUILDCACHE-63:
---

!https://fonts.gstatic.com/s/e/notoemoji/15.0/1f926/72.png!

The documentation is a bit hidden on the importance of 
`-Dmaven.build.cache.remote.save.enabled`.  That fixes the push to the remote.

I still think this bug should be used to get rid of the stack trace when when 
remote build cache is not found. Seems a bit scary (without -e or -X) to see 
that stack trace.

> Remote cache with Nexus raw repository does not work
> 
>
> Key: MBUILDCACHE-63
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-63
> Project: Maven Build Cache Extension
>  Issue Type: Bug
>  Components: remote build cache
>Affects Versions: 1.0.1
> Environment: Apache Maven 3.9.2 
> (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
> Maven home: /opt/maven/apache-maven
> Java version: 19.0.2, vendor: Eclipse Adoptium, runtime: 
> /opt/java/jdk-19.0.2+7
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix"
>Reporter: Ben Tatham
>Priority: Major
>
> I set up a raw repository in Sonatype Nexus to use as the remote build cache. 
> It seems to connect ok, but the it gets a 404 when looking for the build 
> cache, and then does not seem to even attempt uploading it when the build is 
> complete (even though it does save the build cache locally).  I assume this 
> means that the exception at start of the build is disabling the remote cache 
> being saved later in the build.
> I have tried it with and without `dav:` prefix on the url, with same result. 
> -X gives no further details that I can see.
> Let me know if there is anything else I can do to debug this.
> {{[INFO] Attempting to restore project 
> ca.nanometrics.apollo.server:apollo-server-parent from build cache}}
> {{[INFO] Downloading 
> dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
> {{[INFO] Cannot download 
> dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
> {{org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at 
> [https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml],
>  status: 404 
> v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml}}
> {{    at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
> (AbstractHttpClientWagon.java:1191)}}
> {{    at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
> (AbstractHttpClientWagon.java:1140)}}
> {{    at org.apache.maven.wagon.StreamWagon.getInputStream 
> (StreamWagon.java:126)}}
> {{    at org.apache.maven.wagon.StreamWagon.getIfNewerToStream 
> (StreamWagon.java:226)}}
> {{    at org.apache.maven.wagon.StreamWagon.getToStream 
> (StreamWagon.java:262)}}
> {{    at 
> org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run 
> (WagonTransporter.java:427)}}
> {{    at org.eclipse.aether.transport.wagon.WagonTransporter.execute 
> (WagonTransporter.java:367)}}
> {{    at org.eclipse.aether.transport.wagon.WagonTransporter.get 
> (WagonTransporter.java:348)}}
> {{    at 
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent 
> (RemoteCacheRepositoryImpl.java:151)}}
> {{    at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild 
> (RemoteCacheRepositoryImpl.java:108)}}
> {{    at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild 
> (LocalCacheRepositoryImpl.java:169)}}
> {{    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
> (CacheControllerImpl.java:207)}}
> {{    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
> (CacheControllerImpl.java:180)}}
> {{    at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute 
> (BuildCacheMojosExecutionStrategy.java:117)}}
> {{    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:160)}}
> {{    at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:105)}}
> {{    at 
> 

[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735869#comment-17735869
 ] 

ASF GitHub Bot commented on SUREFIRE-2182:
--

kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237540052


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()

Review Comment:
   First https://issues.apache.org/jira/browse/SUREFIRE-2183 needs 
clarification, because for me the latter is not logged when using {{mvn -X}}. 
But it is logged if placed outside the guard in line 1183...





> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735870#comment-17735870
 ] 

ASF GitHub Bot commented on SUREFIRE-2182:
--

kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237540052


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()

Review Comment:
   First https://issues.apache.org/jira/browse/SUREFIRE-2183 needs 
clarification, because for me the newly added line is not logged when using 
{{mvn -X}}. But it is logged if placed outside the guard in line 1183 (both 
with the same level debug).





> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-surefire] kwin commented on a diff in pull request #665: [SUREFIRE-2182] Log starter implementation on DEBUG level

2023-06-21 Thread via GitHub


kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237540052


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()

Review Comment:
   First https://issues.apache.org/jira/browse/SUREFIRE-2183 needs 
clarification, because for me the newly added line is not logged when using 
{{mvn -X}}. But it is logged if placed outside the guard in line 1183 (both 
with the same level debug).



-- 
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-surefire] kwin commented on a diff in pull request #665: [SUREFIRE-2182] Log starter implementation on DEBUG level

2023-06-21 Thread via GitHub


kwin commented on code in PR #665:
URL: https://github.com/apache/maven-surefire/pull/665#discussion_r1237540052


##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1181,6 +1181,9 @@ private RunResult executeProvider(
 } else {
 ForkConfiguration forkConfiguration = 
createForkConfiguration(platform, resolvedJavaModularityResult);
 if (getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()

Review Comment:
   First https://issues.apache.org/jira/browse/SUREFIRE-2183 needs 
clarification, because for me the latter is not logged when using {{mvn -X}}. 
But it is logged if placed outside the guard in line 1183...



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Created] (SUREFIRE-2183) AbstractSurefireLogger.getConsoleLogger().isDebugEnabled() returns false when mvn is executed with "-X"

2023-06-21 Thread Konrad Windszus (Jira)
Konrad Windszus created SUREFIRE-2183:
-

 Summary: 
AbstractSurefireLogger.getConsoleLogger().isDebugEnabled() returns false when 
mvn is executed with "-X"
 Key: SUREFIRE-2183
 URL: https://issues.apache.org/jira/browse/SUREFIRE-2183
 Project: Maven Surefire
  Issue Type: Improvement
  Components: process forking
Affects Versions: 3.1.2
Reporter: Konrad Windszus


Despite the fact that running {{mvn}} with option {{-X}} is supposed to turn on 
all debug statements the logger returned by 
https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L888
  does still return {{false}} for {{isDebugEnabled()}}, therefore logging 
statements like 
https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1183
 are not emitted when {{-X}} or {{--debug}} are set.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (SUREFIRE-2180) Surefire not invoking tests with TestNG DataProvider

2023-06-21 Thread Javier A. Ortiz (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735865#comment-17735865
 ] 

Javier A. Ortiz commented on SUREFIRE-2180:
---

Any hints on where I can find in the code where the invocations happen? I 
assumed that it would be somewhere in the SureFire TestNG Runner module.

> Surefire not invoking tests with TestNG DataProvider
> 
>
> Key: SUREFIRE-2180
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2180
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: TestNG support
>Affects Versions: 3.1.2
>Reporter: Javier A. Ortiz
>Priority: Major
>
> I'm having a weird issue I can't figure out. It's driving me insane.
> I have a Maven project for which I'm running the same command both locally 
> and on Jenkins. The environment is the same as far as I can tell:
>  - Maven 3.9.2 (On Jenkins: Docker image maven:3.9.2-eclipse-temurin-11)
>  - JDK 11 (On Jenkins: Docker image maven:3.9.2-eclipse-temurin-11)
>  - TestNG 7.8.0
> Command:
> {code:java}
> mvn -Ddependency.surefire.verbose=10 -Pcoverage verify -B -U -Dgroup=PLATFORM
> {code}
> Relevant POM section:
> {code:java}
> 
> 
>   
> 
>   org.jacoco
>   jacoco-maven-plugin
>   0.8.10
> 
> ...
>   
> 
> ...
> 
> ...
> 
> 
>   coverage
>   
> 
>   
> org.jacoco
> jacoco-maven-plugin
> 
>   
> com/XXX/framework/dataproviders/**/*
> com/XXX/v2/basetest/**/*
> **/*Exception*
>   
> 
> 
>   
> 
>   prepare-agent
> 
>   
>   
>   
> report
> test
> 
>   report
> 
>   
>   
>   
> jacoco-check
> 
>   check
> 
> 
>   
> 
>   BUNDLE
>   
> 
>   INSTRUCTION
>   COVEREDRATIO
>   60%
> 
> 
>   CLASS
>   MISSEDCOUNT
>   0
> 
>   
> 
> 
>   PACKAGE
>   
> 
>   LINE
>   COVEREDRATIO
>   60%
> 
>   
> 
>   
>   ${skipTests}
> 
>   
> 
>   
> 
>   
> 
> {code}
> One of the tests that have the issue (only tests with DataProviders) show 
> this pattern in the logs. Enabled verbose to level 10 in hopes that something 
> would show up.
> Locally:
> {code:java}
> [2023-06-06 16:55:46.795] [INFO] [TestClass] Creating TestClass for 
> [ClassImpl class=com.XXX.framework.utils.TimeUtilsTest]
> [2023-06-06 16:55:46.796] [INFO] Method public java.lang.Object[][] 
> com.XXX.framework.utils.TimeUtilsTest.getTimeData() has a @Test annotation 
> but also a return value: ignoring it. Use  
> to fix this
> [2023-06-06 16:55:46.797] [INFO] [TestClass] Adding method 
> TimeUtilsTest.testToFormattedString(java.util.concurrent.TimeUnit,int,java.lang.String,com.XXX.framework.annotations.TestNameParameter)[pri:0,
>  instance:null] on TestClass class com.XXX.framework.utils.TimeUtilsTest
> {code}
> ...
> {code:java}
> [2023-06-06 16:55:47.316] [INFO] = Test class
> com.XXX.framework.utils.TimeUtilsTest
> [2023-06-06 16:55:47.316] [INFO] @Test 
> TimeUtilsTest.testToFormattedString(java.util.concurrent.TimeUnit,int,java.lang.String,com.XXX.framework.annotations.TestNameParameter)[pri:0,
>  instance:com.XXX.framework.utils.TimeUtilsTest@283eb984]
> [2023-06-06 16:55:47.316] [INFO] ==
> {code}
> ...
> {code:java}
> [TestNG] INVOKING: "Surefire test" - 
> com.XXX.framework.utils.TimeUtilsTest.testToFormattedString(java.util.concurrent.TimeUnit,int,java.lang.String,com.XXX.framework.annotations.TestNameParameter)(value(s):
>  NANOSECONDS, 60, "60ns", TestNameParameter(customName=60 NANOSECONDS))
> {code}
> ...
> Test executes and results, etc.
> On Jenkins:
> {code:java}
> [2023-06-06 21:02:29.270] [INFO] [TestClass] Creating TestClass for 
> [ClassImpl class=com.XXX.framework.utils.TimeUtilsTest]
> [2023-06-06 21:02:29.271] [INFO] Method public 

[jira] [Commented] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735860#comment-17735860
 ] 

ASF GitHub Bot commented on SUREFIRE-2182:
--

kwin opened a new pull request, #665:
URL: https://github.com/apache/maven-surefire/pull/665

   For fork starter log the underlying configuration class name as well
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/SUREFIRE) 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.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `SUREFIRE-XXX` 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.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean install` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean 
install`).
   
   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.
   
- [x] 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).
   




> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-surefire] kwin opened a new pull request, #665: [SUREFIRE-2182] Log starter implementation on DEBUG level

2023-06-21 Thread via GitHub


kwin opened a new pull request, #665:
URL: https://github.com/apache/maven-surefire/pull/665

   For fork starter log the underlying configuration class name as well
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/SUREFIRE) 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.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `SUREFIRE-XXX` 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.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean install` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean 
install`).
   
   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.
   
- [x] 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).
   


-- 
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] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread Konrad Windszus (Jira)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SUREFIRE-2182:
--
Summary: Log starter implementation on DEBUG level  (was: Log 
ForkConfiguration implementation on DEBUG level)

> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread Konrad Windszus (Jira)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SUREFIRE-2182:
--
Description: In order to ease debugging classpath issues the fork 
configuration determined by 
[AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
 should be logged with debug level for when using the fork starter. Similarly a 
DEBUG log entry should be emitted when the in-process starter is being used.  
(was: In order to ease debugging classpath issues the fork configuration 
determined by 
[AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
 should be logged with debug level.)

> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (SUREFIRE-2182) Log starter implementation on DEBUG level

2023-06-21 Thread Konrad Windszus (Jira)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned SUREFIRE-2182:
-

Assignee: Konrad Windszus

> Log starter implementation on DEBUG level
> -
>
> Key: SUREFIRE-2182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In order to ease debugging classpath issues the fork configuration determined 
> by 
> [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
>  should be logged with debug level for when using the fork starter. Similarly 
> a DEBUG log entry should be emitted when the in-process starter is being used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (SUREFIRE-2182) Log ForkConfiguration implementation on DEBUG level

2023-06-21 Thread Konrad Windszus (Jira)
Konrad Windszus created SUREFIRE-2182:
-

 Summary: Log ForkConfiguration implementation on DEBUG level
 Key: SUREFIRE-2182
 URL: https://issues.apache.org/jira/browse/SUREFIRE-2182
 Project: Maven Surefire
  Issue Type: Improvement
Reporter: Konrad Windszus


In order to ease debugging classpath issues the fork configuration determined 
by 
[AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216]
 should be logged with debug level.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work

2023-06-21 Thread Tamas Cservenak (Jira)


[ 
https://issues.apache.org/jira/browse/MBUILDCACHE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735848#comment-17735848
 ] 

Tamas Cservenak commented on MBUILDCACHE-63:


Raw repository should not need {{dav:}} prefix, do not use it. Use plain 
(preferably modern) transport and that should do it.

> Remote cache with Nexus raw repository does not work
> 
>
> Key: MBUILDCACHE-63
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-63
> Project: Maven Build Cache Extension
>  Issue Type: Bug
>  Components: remote build cache
>Affects Versions: 1.0.1
> Environment: Apache Maven 3.9.2 
> (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
> Maven home: /opt/maven/apache-maven
> Java version: 19.0.2, vendor: Eclipse Adoptium, runtime: 
> /opt/java/jdk-19.0.2+7
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix"
>Reporter: Ben Tatham
>Priority: Major
>
> I set up a raw repository in Sonatype Nexus to use as the remote build cache. 
> It seems to connect ok, but the it gets a 404 when looking for the build 
> cache, and then does not seem to even attempt uploading it when the build is 
> complete (even though it does save the build cache locally).  I assume this 
> means that the exception at start of the build is disabling the remote cache 
> being saved later in the build.
> I have tried it with and without `dav:` prefix on the url, with same result. 
> -X gives no further details that I can see.
> Let me know if there is anything else I can do to debug this.
> {{[INFO] Attempting to restore project 
> ca.nanometrics.apollo.server:apollo-server-parent from build cache}}
> {{[INFO] Downloading 
> dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
> {{[INFO] Cannot download 
> dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
> {{org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at 
> [https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml],
>  status: 404 
> v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml}}
> {{    at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
> (AbstractHttpClientWagon.java:1191)}}
> {{    at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
> (AbstractHttpClientWagon.java:1140)}}
> {{    at org.apache.maven.wagon.StreamWagon.getInputStream 
> (StreamWagon.java:126)}}
> {{    at org.apache.maven.wagon.StreamWagon.getIfNewerToStream 
> (StreamWagon.java:226)}}
> {{    at org.apache.maven.wagon.StreamWagon.getToStream 
> (StreamWagon.java:262)}}
> {{    at 
> org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run 
> (WagonTransporter.java:427)}}
> {{    at org.eclipse.aether.transport.wagon.WagonTransporter.execute 
> (WagonTransporter.java:367)}}
> {{    at org.eclipse.aether.transport.wagon.WagonTransporter.get 
> (WagonTransporter.java:348)}}
> {{    at 
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent 
> (RemoteCacheRepositoryImpl.java:151)}}
> {{    at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild 
> (RemoteCacheRepositoryImpl.java:108)}}
> {{    at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild 
> (LocalCacheRepositoryImpl.java:169)}}
> {{    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
> (CacheControllerImpl.java:207)}}
> {{    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
> (CacheControllerImpl.java:180)}}
> {{    at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute 
> (BuildCacheMojosExecutionStrategy.java:117)}}
> {{    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:160)}}
> {{    at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:105)}}
> {{    at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:73)}}
> {{    at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:53)}}
> {{    at 

[jira] [Updated] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work

2023-06-21 Thread Ben Tatham (Jira)


 [ 
https://issues.apache.org/jira/browse/MBUILDCACHE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ben Tatham updated MBUILDCACHE-63:
--
Description: 
I set up a raw repository in Sonatype Nexus to use as the remote build cache. 
It seems to connect ok, but the it gets a 404 when looking for the build cache, 
and then does not seem to even attempt uploading it when the build is complete 
(even though it does save the build cache locally).  I assume this means that 
the exception at start of the build is disabling the remote cache being saved 
later in the build.

I have tried it with and without `dav:` prefix on the url, with same result. 

-X gives no further details that I can see.

Let me know if there is anything else I can do to debug this.


{{[INFO] Attempting to restore project 
ca.nanometrics.apollo.server:apollo-server-parent from build cache}}
{{[INFO] Downloading 
dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
{{[INFO] Cannot download 
dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
{{org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at 
[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml],
 status: 404 
v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml}}
{{    at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
(AbstractHttpClientWagon.java:1191)}}
{{    at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
(AbstractHttpClientWagon.java:1140)}}
{{    at org.apache.maven.wagon.StreamWagon.getInputStream 
(StreamWagon.java:126)}}
{{    at org.apache.maven.wagon.StreamWagon.getIfNewerToStream 
(StreamWagon.java:226)}}
{{    at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)}}
{{    at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run 
(WagonTransporter.java:427)}}
{{    at org.eclipse.aether.transport.wagon.WagonTransporter.execute 
(WagonTransporter.java:367)}}
{{    at org.eclipse.aether.transport.wagon.WagonTransporter.get 
(WagonTransporter.java:348)}}
{{    at 
org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent 
(RemoteCacheRepositoryImpl.java:151)}}
{{    at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild 
(RemoteCacheRepositoryImpl.java:108)}}
{{    at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild 
(LocalCacheRepositoryImpl.java:169)}}
{{    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
(CacheControllerImpl.java:207)}}
{{    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
(CacheControllerImpl.java:180)}}
{{    at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute 
(BuildCacheMojosExecutionStrategy.java:117)}}
{{    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:160)}}
{{    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:105)}}
{{    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:73)}}
{{    at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:53)}}
{{    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:118)}}
{{    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)}}
{{    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)}}
{{    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)}}
{{    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)}}
{{    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)}}
{{    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)}}
{{    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke 
(DirectMethodHandleAccessor.java:104)}}
{{    at java.lang.reflect.Method.invoke (Method.java:578)}}
{{    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:283)}}
{{    at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:226)}}
{{    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:407)}}
{{    at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:348)}}
{{[INFO] Remote cache is incomplete or 

[jira] [Created] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work

2023-06-21 Thread Ben Tatham (Jira)
Ben Tatham created MBUILDCACHE-63:
-

 Summary: Remote cache with Nexus raw repository does not work
 Key: MBUILDCACHE-63
 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-63
 Project: Maven Build Cache Extension
  Issue Type: Bug
  Components: remote build cache
Affects Versions: 1.0.1
 Environment: Apache Maven 3.9.2 
(c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
Maven home: /opt/maven/apache-maven
Java version: 19.0.2, vendor: Eclipse Adoptium, runtime: /opt/java/jdk-19.0.2+7
Default locale: en_CA, platform encoding: UTF-8
OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix"

Reporter: Ben Tatham


I set up a raw repository in Sonatype Nexus to use as the remote build cache. 
It seems to connect ok, but the it gets a 404 when looking for the build cache, 
and then does not seem to even attempt uploading it when the build is complete 
(even though it does save the build cache locally).  I assume this means that 
the exception at start of the build is disabling the remote cache being saved 
later in the build.

I have tried it with and without `dav:` prefix on the url, with same result. 

-X gives no further details that I can see.

Let me know if there is anything else I can do to debug this.


```
[INFO] Attempting to restore project 
ca.nanometrics.apollo.server:apollo-server-parent from build cache
[INFO] Downloading 
dav:https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml
[INFO] Cannot download 
dav:https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml
org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at 
https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml,
 status: 404 
v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
(AbstractHttpClientWagon.java:1191)
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData 
(AbstractHttpClientWagon.java:1140)
    at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)
    at org.apache.maven.wagon.StreamWagon.getIfNewerToStream 
(StreamWagon.java:226)
    at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)
    at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run 
(WagonTransporter.java:427)
    at org.eclipse.aether.transport.wagon.WagonTransporter.execute 
(WagonTransporter.java:367)
    at org.eclipse.aether.transport.wagon.WagonTransporter.get 
(WagonTransporter.java:348)
    at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent 
(RemoteCacheRepositoryImpl.java:151)
    at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild 
(RemoteCacheRepositoryImpl.java:108)
    at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild 
(LocalCacheRepositoryImpl.java:169)
    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
(CacheControllerImpl.java:207)
    at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild 
(CacheControllerImpl.java:180)
    at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute 
(BuildCacheMojosExecutionStrategy.java:117)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:160)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:73)
    at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke 
(DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:578)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:348)
[INFO] Remote cache is incomplete or 

[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread Lenny Primak (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735820#comment-17735820
 ] 

Lenny Primak commented on MNG-7818:
---

This will not cause any issuers since test dependencies are not transitive, as 
@cstamas said



> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread Lenny Primak (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735819#comment-17735819
 ] 

Lenny Primak commented on MNG-7818:
---

This will not cause any issuers since test dependencies are not transitive, as 
@cstamas said



> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit

2023-06-21 Thread Elliotte Rusty Harold (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735776#comment-17735776
 ] 

Elliotte Rusty Harold commented on MNG-7818:


The might cause problems with dependency analysis. Hamcrest is a bit of a mess 
since it moved classes between packages in version 2. 

> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes 
> ClassNotFouncException
> BTW: Using hamcrest-core  2.2 (as opposed to 1.3 and without exclusions) with 
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time 
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>   at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
>   at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
>   at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
>   at java.base/java.lang.Class.getConstructor0(Class.java:3678)
>   at java.base/java.lang.Class.getConstructor(Class.java:2368)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>   at 
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
>   at 
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
>   at 
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
>   at 
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   ... 28 more  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7302) Replace construction of FileInputStream and FileOutputStream objects with Files NIO APIs.

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735760#comment-17735760
 ] 

ASF GitHub Bot commented on MNG-7302:
-

arturobernalg closed pull request #587: [MNG-7302] - Replace construction of 
FileInputStream and FileOutputStream objects with Files NIO APIs.
URL: https://github.com/apache/maven/pull/587




> Replace construction of FileInputStream and FileOutputStream objects with 
> Files NIO APIs.
> -
>
> Key: MNG-7302
> URL: https://issues.apache.org/jira/browse/MNG-7302
> Project: Maven
>  Issue Type: Sub-task
>Reporter: Arturo Bernal
>Priority: Minor
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7416) Simplify conditional expression.

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735761#comment-17735761
 ] 

ASF GitHub Bot commented on MNG-7416:
-

arturobernalg closed pull request #679: MNG-7416 - Simplify conditional 
expression.
URL: https://github.com/apache/maven/pull/679




> Simplify conditional expression.
> 
>
> Key: MNG-7416
> URL: https://issues.apache.org/jira/browse/MNG-7416
> Project: Maven
>  Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Minor
>
> Simplify conditional expression and avoid extra computations. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] arturobernalg closed pull request #587: [MNG-7302] - Replace construction of FileInputStream and FileOutputStream objects with Files NIO APIs.

2023-06-21 Thread via GitHub


arturobernalg closed pull request #587: [MNG-7302] - Replace construction of 
FileInputStream and FileOutputStream objects with Files NIO APIs.
URL: https://github.com/apache/maven/pull/587


-- 
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] arturobernalg closed pull request #679: MNG-7416 - Simplify conditional expression.

2023-06-21 Thread via GitHub


arturobernalg closed pull request #679: MNG-7416 - Simplify conditional 
expression.
URL: https://github.com/apache/maven/pull/679


-- 
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] [Resolved] (MNG-7714) sp < final

2023-06-21 Thread Elliotte Rusty Harold (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold resolved MNG-7714.

Resolution: Fixed

fixed at head. This one would b worth backporting to 3.9.

> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-7
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec. 
> It is easy to demonstrate that this is not fixed and also not in line with 
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001 
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of 
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat, 
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001 
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of 
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, 
> [1]
> As you can see, our `sp` release is now ordered after our `final` release 
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for 
> the following tokens which come first in this order: "alpha" < "beta" < 
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable 
> measurement, and breaking large amounts of (our) existing artifacts in the 
> wild is definitely not OK.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7714) sp < final

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735713#comment-17735713
 ] 

ASF GitHub Bot commented on MNG-7714:
-

elharo merged PR #1099:
URL: https://github.com/apache/maven/pull/1099




> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-7
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec. 
> It is easy to demonstrate that this is not fixed and also not in line with 
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001 
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of 
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat, 
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001 
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of 
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, 
> [1]
> As you can see, our `sp` release is now ordered after our `final` release 
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for 
> the following tokens which come first in this order: "alpha" < "beta" < 
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable 
> measurement, and breaking large amounts of (our) existing artifacts in the 
> wild is definitely not OK.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] elharo merged pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final

2023-06-21 Thread via GitHub


elharo merged PR #1099:
URL: https://github.com/apache/maven/pull/1099


-- 
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] cstamas merged pull request #271: [MNG-7819] Add IT that excercise the bug

2023-06-21 Thread via GitHub


cstamas merged PR #271:
URL: https://github.com/apache/maven-integration-testing/pull/271


-- 
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] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils

2023-06-21 Thread Elliotte Rusty Harold (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735687#comment-17735687
 ] 

Elliotte Rusty Harold commented on MSHARED-1274:


Hmm, not sure about plexus-xml but these classes do not, contrary to what I 
thought, use XPP3. They're based on the JDK's SAX parser. However they don't 
configure it properly for namespaces, and they're still not used anywhere so 
probably OK to delete. 

> Deprecate the xml bits from maven-shared-utils
> --
>
> Key: MSHARED-1274
> URL: https://issues.apache.org/jira/browse/MSHARED-1274
> Project: Maven Shared Components
>  Issue Type: Task
>  Components: maven-shared-utils
>Reporter: Guillaume Nodet
>Priority: Major
>
> The xml bits from plexus-utils are a de-facto part of the maven 3.x api and 
> we should not have two conflicting versions of it.  Now that it has been 
> extract in a separate project in plexus-xml, I think it is time to deprecate 
> those classes in maven-shared-utils.  Fwiw, the core implementation classes 
> are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom 
> class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl 
> class from maven, however the parser is still present in plexus-xml.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735683#comment-17735683
 ] 

ASF GitHub Bot commented on MSHARED-1274:
-

elharo opened a new pull request, #162:
URL: https://github.com/apache/maven-shared-utils/pull/162

   These classes have no usage in Apache Maven and extremely limited use 
anywhere else. 




> Deprecate the xml bits from maven-shared-utils
> --
>
> Key: MSHARED-1274
> URL: https://issues.apache.org/jira/browse/MSHARED-1274
> Project: Maven Shared Components
>  Issue Type: Task
>  Components: maven-shared-utils
>Reporter: Guillaume Nodet
>Priority: Major
>
> The xml bits from plexus-utils are a de-facto part of the maven 3.x api and 
> we should not have two conflicting versions of it.  Now that it has been 
> extract in a separate project in plexus-xml, I think it is time to deprecate 
> those classes in maven-shared-utils.  Fwiw, the core implementation classes 
> are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom 
> class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl 
> class from maven, however the parser is still present in plexus-xml.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils

2023-06-21 Thread Elliotte Rusty Harold (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735680#comment-17735680
 ] 

Elliotte Rusty Harold commented on MSHARED-1274:


org.apache.maven.shared.utils.xml.PrettyPrintXmlWriter does seem to be used 
here and there:

https://github.com/search?q=org.apache.maven.shared.utils.xml.PrettyPrintXmlWriter=code

However, it's likely to be separable from the rest of this package. 

> Deprecate the xml bits from maven-shared-utils
> --
>
> Key: MSHARED-1274
> URL: https://issues.apache.org/jira/browse/MSHARED-1274
> Project: Maven Shared Components
>  Issue Type: Task
>  Components: maven-shared-utils
>Reporter: Guillaume Nodet
>Priority: Major
>
> The xml bits from plexus-utils are a de-facto part of the maven 3.x api and 
> we should not have two conflicting versions of it.  Now that it has been 
> extract in a separate project in plexus-xml, I think it is time to deprecate 
> those classes in maven-shared-utils.  Fwiw, the core implementation classes 
> are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom 
> class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl 
> class from maven, however the parser is still present in plexus-xml.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-shared-utils] elharo opened a new pull request, #161: remove vestigial comments

2023-06-21 Thread via GitHub


elharo opened a new pull request, #161:
URL: https://github.com/apache/maven-shared-utils/pull/161

   probably some old copy pasta


-- 
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] cstamas commented on a diff in pull request #271: [MNG-7819] Add IT that excercise the bug

2023-06-21 Thread via GitHub


cstamas commented on code in PR #271:
URL: 
https://github.com/apache/maven-integration-testing/pull/271#discussion_r1236850777


##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7819FileLockingWithSnapshotsTest.java:
##
@@ -0,0 +1,105 @@
+/*
+ * 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.
+ */
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.commons.io.FileUtils;
+import org.apache.maven.shared.verifier.Verifier;
+import org.apache.maven.shared.verifier.util.ResourceExtractor;
+import org.eclipse.jetty.server.Handler;
+import org.eclipse.jetty.server.NetworkConnector;
+import org.eclipse.jetty.server.Server;
+import org.eclipse.jetty.server.handler.HandlerList;
+import org.eclipse.jetty.server.handler.ResourceHandler;
+import org.junit.jupiter.api.AfterEach;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+
+class MavenITmng7819FileLockingWithSnapshotsTest extends 
AbstractMavenIntegrationTestCase {
+
+private Server server;
+
+private int port;
+
+protected MavenITmng7819FileLockingWithSnapshotsTest() {
+// broken: maven 3.9.2 and 4.0.0-alpha-5
+super("[3.9.0,3.9.2),(3.9.2,],[4.0.0-alpha-6,)");

Review Comment:
   bah, no, would skip 3.9.3...



-- 
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] cstamas commented on a diff in pull request #271: [MNG-7819] Add IT that excercise the bug

2023-06-21 Thread via GitHub


cstamas commented on code in PR #271:
URL: 
https://github.com/apache/maven-integration-testing/pull/271#discussion_r1236846098


##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7819FileLockingWithSnapshotsTest.java:
##
@@ -0,0 +1,105 @@
+/*
+ * 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.
+ */
+package org.apache.maven.it;
+
+import java.io.File;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.commons.io.FileUtils;
+import org.apache.maven.shared.verifier.Verifier;
+import org.apache.maven.shared.verifier.util.ResourceExtractor;
+import org.eclipse.jetty.server.Handler;
+import org.eclipse.jetty.server.NetworkConnector;
+import org.eclipse.jetty.server.Server;
+import org.eclipse.jetty.server.handler.HandlerList;
+import org.eclipse.jetty.server.handler.ResourceHandler;
+import org.junit.jupiter.api.AfterEach;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+
+class MavenITmng7819FileLockingWithSnapshotsTest extends 
AbstractMavenIntegrationTestCase {
+
+private Server server;
+
+private int port;
+
+protected MavenITmng7819FileLockingWithSnapshotsTest() {
+// broken: maven 3.9.2 and 4.0.0-alpha-5
+super("[3.9.0,3.9.2),(3.9.2,],[4.0.0-alpha-6,)");

Review Comment:
   [3.9.0,3.9.2),(3.9.2,4.0.0-alpha-5),[4.0.0-alpha-6,) instead?



-- 
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] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils

2023-06-21 Thread Elliotte Rusty Harold (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735658#comment-17735658
 ] 

Elliotte Rusty Harold commented on MSHARED-1274:


"fast and lightweight" is often a euphemism for, "Does not correctly implement 
the XML spec"

The problem with governance is not that it's not inside the ASF. It's that 
ownership, licensing, and development of plexus is very murky. None of that 
matters until some company buys some other company and the new lawyers go 
looking for a way to extract rents from existing IP. Even if you win, 
responding to the lawsuits can easily cost millions. Yes, this has happened 
multiple times in the past and it will happen in the future. 

> Deprecate the xml bits from maven-shared-utils
> --
>
> Key: MSHARED-1274
> URL: https://issues.apache.org/jira/browse/MSHARED-1274
> Project: Maven Shared Components
>  Issue Type: Task
>  Components: maven-shared-utils
>Reporter: Guillaume Nodet
>Priority: Major
>
> The xml bits from plexus-utils are a de-facto part of the maven 3.x api and 
> we should not have two conflicting versions of it.  Now that it has been 
> extract in a separate project in plexus-xml, I think it is time to deprecate 
> those classes in maven-shared-utils.  Fwiw, the core implementation classes 
> are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom 
> class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl 
> class from maven, however the parser is still present in plexus-xml.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MDEP-875) Regression: list-repositories may produce NPE

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735649#comment-17735649
 ] 

ASF GitHub Bot commented on MDEP-875:
-

slawekjaranowski commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1236761294


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   check in line 101 - ok
   
   > "No remote repository is used by this build." 
   
   will be ok
   
   
   





> Regression: list-repositories may produce NPE
> -
>
> Key: MDEP-875
> URL: https://issues.apache.org/jira/browse/MDEP-875
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: list-repositories
>Affects Versions: 3.6.0
>Reporter: Rostislav Krasny
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Running the *{{mvn 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories}}* 
> command on a projects that has no repository with mirror or only repositories 
> with mirrors fails with an NPE like in the following example:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> (default-cli) on project d
> emo: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> failed: Cannot invoke
> "java.util.Collection.forEach(java.util.function.Consumer)" because 
> "remoteProjectRepositories" is null -> [Help 1]
> The "project demo" is a simple default project made by 
> https://start.spring.io/
> This regression was introduced by fix of MDEP-853 and exists only in the 
> {{3.6.0}} version of the plugin.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-dependency-plugin] slawekjaranowski commented on a diff in pull request #328: MDEP-875 prevent possible NPE

2023-06-21 Thread via GitHub


slawekjaranowski commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1236761294


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   check in line 101 - ok
   
   > "No remote repository is used by this build." 
   
   will be ok
   
   
   



-- 
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] (MDEP-875) Regression: list-repositories may produce NPE

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735616#comment-17735616
 ] 

ASF GitHub Bot commented on MDEP-875:
-

rosti-il commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1236665469


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   In case of an empty list is passed to the 
`prepareRemoteMirrorRepositoriesList()` it doesn't add anything into the 
`message`, so no check is necessary there. The 
`prepareRemoteRepositoriesList()` that is called before 
`prepareRemoteMirrorRepositoriesList()` always appends this title message:
   ```java
   message.append("Project remote repositories used by this 
build:").append(System.lineSeparator());
   ```
   Not appending this title message in `prepareRemoteRepositoriesList()` when 
`prepareRemoteMirrorRepositoriesList()` prints something will look bad, IMHO.
   
   I think a better solution would be checking `repositories.isEmpty()` before 
line 101 and if it is empty just print some other title message and exit from 
`doExecute()`. Would you like me to change this pull request this way? What 
title message for the case of empty `repositories` would you like to be 
printed? For example: "No remote repository is used by this build."





> Regression: list-repositories may produce NPE
> -
>
> Key: MDEP-875
> URL: https://issues.apache.org/jira/browse/MDEP-875
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: list-repositories
>Affects Versions: 3.6.0
>Reporter: Rostislav Krasny
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Running the *{{mvn 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories}}* 
> command on a projects that has no repository with mirror or only repositories 
> with mirrors fails with an NPE like in the following example:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> (default-cli) on project d
> emo: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> failed: Cannot invoke
> "java.util.Collection.forEach(java.util.function.Consumer)" because 
> "remoteProjectRepositories" is null -> [Help 1]
> The "project demo" is a simple default project made by 
> https://start.spring.io/
> This regression was introduced by fix of MDEP-853 and exists only in the 
> {{3.6.0}} version of the plugin.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-dependency-plugin] rosti-il commented on a diff in pull request #328: MDEP-875 prevent possible NPE

2023-06-21 Thread via GitHub


rosti-il commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1236665469


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   In case of an empty list is passed to the 
`prepareRemoteMirrorRepositoriesList()` it doesn't add anything into the 
`message`, so no check is necessary there. The 
`prepareRemoteRepositoriesList()` that is called before 
`prepareRemoteMirrorRepositoriesList()` always appends this title message:
   ```java
   message.append("Project remote repositories used by this 
build:").append(System.lineSeparator());
   ```
   Not appending this title message in `prepareRemoteRepositoriesList()` when 
`prepareRemoteMirrorRepositoriesList()` prints something will look bad, IMHO.
   
   I think a better solution would be checking `repositories.isEmpty()` before 
line 101 and if it is empty just print some other title message and exit from 
`doExecute()`. Would you like me to change this pull request this way? What 
title message for the case of empty `repositories` would you like to be 
printed? For example: "No remote repository is used by this build."



-- 
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] (MDEP-875) Regression: list-repositories may produce NPE

2023-06-21 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735606#comment-17735606
 ] 

ASF GitHub Bot commented on MDEP-875:
-

slawekjaranowski commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1236603544


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   We can also check in methods `prepareRemote*` if list is empty to avoid 
produce incomplete message.





> Regression: list-repositories may produce NPE
> -
>
> Key: MDEP-875
> URL: https://issues.apache.org/jira/browse/MDEP-875
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: list-repositories
>Affects Versions: 3.6.0
>Reporter: Rostislav Krasny
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Running the *{{mvn 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories}}* 
> command on a projects that has no repository with mirror or only repositories 
> with mirrors fails with an NPE like in the following example:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> (default-cli) on project d
> emo: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> failed: Cannot invoke
> "java.util.Collection.forEach(java.util.function.Consumer)" because 
> "remoteProjectRepositories" is null -> [Help 1]
> The "project demo" is a simple default project made by 
> https://start.spring.io/
> This regression was introduced by fix of MDEP-853 and exists only in the 
> {{3.6.0}} version of the plugin.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-dependency-plugin] slawekjaranowski commented on a diff in pull request #328: MDEP-875 prevent possible NPE

2023-06-21 Thread via GitHub


slawekjaranowski commented on code in PR #328:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/328#discussion_r1236603544


##
src/main/java/org/apache/maven/plugins/dependency/ListRepositoriesMojo.java:
##
@@ -104,8 +104,10 @@ public boolean visitLeave(DependencyNode node) {
 .collect(Collectors.groupingBy(
 repo -> repo.getMirroredRepositories().isEmpty()));
 
-prepareRemoteRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.TRUE));
-prepareRemoteMirrorRepositoriesList(message, 
repoGroupByMirrors.get(Boolean.FALSE));
+prepareRemoteRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.TRUE, 
Collections.emptyList()));
+prepareRemoteMirrorRepositoriesList(
+message, repoGroupByMirrors.getOrDefault(Boolean.FALSE, 
Collections.emptyList()));

Review Comment:
   We can also check in methods `prepareRemote*` if list is empty to avoid 
produce incomplete message.



-- 
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] [Assigned] (MDEP-875) Regression: list-repositories may produce NPE

2023-06-21 Thread Slawomir Jaranowski (Jira)


 [ 
https://issues.apache.org/jira/browse/MDEP-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Slawomir Jaranowski reassigned MDEP-875:


Assignee: Slawomir Jaranowski

> Regression: list-repositories may produce NPE
> -
>
> Key: MDEP-875
> URL: https://issues.apache.org/jira/browse/MDEP-875
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: list-repositories
>Affects Versions: 3.6.0
>Reporter: Rostislav Krasny
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Running the *{{mvn 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories}}* 
> command on a projects that has no repository with mirror or only repositories 
> with mirrors fails with an NPE like in the following example:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> (default-cli) on project d
> emo: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.6.0:list-repositories 
> failed: Cannot invoke
> "java.util.Collection.forEach(java.util.function.Consumer)" because 
> "remoteProjectRepositories" is null -> [Help 1]
> The "project demo" is a simple default project made by 
> https://start.spring.io/
> This regression was introduced by fix of MDEP-853 and exists only in the 
> {{3.6.0}} version of the plugin.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-mvnd] ljp190 opened a new issue, #861: An Exception On Win11 And JDK11

2023-06-21 Thread via GitHub


ljp190 opened a new issue, #861:
URL: https://github.com/apache/maven-mvnd/issues/861

   I don't know what I did to the windows11  i9 12900H + 16G
   I just downloaded window-amd64.zip  and configure  mavend_home  path
   
   mvnd -version   
   An exception was triggered
   
[daemon-3b9a9cb6.log](https://github.com/apache/maven-mvnd/files/11814723/daemon-3b9a9cb6.log)
   
![image](https://github.com/apache/maven-mvnd/assets/41749016/20fe039e-d4d2-4ccb-906e-9702ae1d993a)
   
   0.8.2   0.9.0   1.0-m6   There's always this exception 
   
   pls look at me
   pls look at me
   pls look at 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.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils

2023-06-21 Thread Guillaume Nodet (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735563#comment-17735563
 ] 

Guillaume Nodet commented on MSHARED-1274:
--

Fwiw, I don't see any real problem with the plexus-xml bits. The parser is very 
fast and lightweight and I would be opposed to switching to a different parser 
at this point.  And the Xpp3Dom is now empty (because the real implementation 
is now in maven).

I don't really see the problem with the "governance" either.  Not all projects 
have to be inside the ASF to be able to be consumed by maven.

> Deprecate the xml bits from maven-shared-utils
> --
>
> Key: MSHARED-1274
> URL: https://issues.apache.org/jira/browse/MSHARED-1274
> Project: Maven Shared Components
>  Issue Type: Task
>  Components: maven-shared-utils
>Reporter: Guillaume Nodet
>Priority: Major
>
> The xml bits from plexus-utils are a de-facto part of the maven 3.x api and 
> we should not have two conflicting versions of it.  Now that it has been 
> extract in a separate project in plexus-xml, I think it is time to deprecate 
> those classes in maven-shared-utils.  Fwiw, the core implementation classes 
> are mainly implemented with Maven 4.x maven-xml-impl module, and the Xpp3Dom 
> class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl 
> class from maven, however the parser is still present in plexus-xml.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-integration-testing] gnodet opened a new pull request, #272: Fix ITs for BOM packaging / build pom

2023-06-21 Thread via GitHub


gnodet opened a new pull request, #272:
URL: https://github.com/apache/maven-integration-testing/pull/272

   (no comment)


-- 
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