[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[ 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
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
[ 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
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
[ 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
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
[ 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
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
[ 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
[ 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
[ 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
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
[ 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
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
[ 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
[ 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
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
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
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
[ 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
[ 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
[ 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
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
[ 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
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"
[ 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
[ 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
[ 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
[ 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
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
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"
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
[ 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
[ 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
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
[ 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
[ 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
[ 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
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
[ 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
[ 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
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
[ 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
[ 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
[ 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.
[ 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.
[ 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.
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.
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
[ 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
[ 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
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
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
[ 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
[ 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
[ 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
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
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
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
[ 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
[ 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
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
[ 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
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
[ 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
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
[ 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
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
[ 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
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