[jira] [Commented] (SUREFIRE-1932) Periodic parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380378#comment-17380378
]
EVGENII STRATOVICH commented on SUREFIRE-1932:
--
[~tibordigana], good day! I've just answered!
Thank you!
> Periodic parallel execution of tests
>
>
> Key: SUREFIRE-1932
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1932
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin, process forking
>Affects Versions: 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, 3.0.0-M4, 3.0.0-M5
>Reporter: EVGENII STRATOVICH
>Priority: Trivial
>
> For parallel testing is used next stack of technologies: java 8 (openjdk
> version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10),
> OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium,
> Selenide, Selenoid etc.
> From time to time during execution I encounter different problem associated
> with maven surefire. I perform parallel testing using Jenkins and jenkins
> file:
>
> {code:java}
> stage('First suite'){
> parallel {
> stage('1 test'){
> }
> stage('2 test'){
> }
> }
> }
> {code}
> but periodically got error and failed stage due to failed test. Fragment of
> trace with error:
> {code:java}
> ExecutionException Error creating properties files for forking
> org.apache.maven.surefire.booter.SurefireBooterForkException:
> ExecutionException Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException:
> Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
[jira] [Updated] (SUREFIRE-1932) Periodic parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EVGENII STRATOVICH updated SUREFIRE-1932:
-
Description:
For parallel testing is used next stack of technologies: java 8 (openjdk
version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10), OpenJDK
64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium, Selenide,
Selenoid etc.
>From time to time during execution I encounter different problem associated
>with maven surefire. I perform parallel testing using Jenkins and jenkins file:
{code:java}
stage('First suite'){
parallel {
stage('1 test'){
}
stage('2 test'){
}
}
}
{code}
but periodically got error and failed stage due to failed test. Fragment of
trace with error:
{code:java}
ExecutionException Error creating properties files for forking
org.apache.maven.surefire.booter.SurefireBooterForkException:
ExecutionException Error creating properties files for forking at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error
creating properties files for forking at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: No
such file or directory at java.io.UnixFileSystem.createFileExclusively(Native
Method) at java.io.File.createTempFile(File.java:2063) at
org.apache.maven.surefire.booter.SystemPropertyManager.writePropertiesFile(SystemPropertyManager.java:77)
at
org.apache.maven.plugin.surefire.booterclient.BooterSerializer.serialize(BooterSerializer.java:187)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:585)
... 7 more
{code}
As well I described my problem here in stackoverflow but with another trace
(URL is attached).
[GitHub] [maven-shared-utils] guylabs commented on a change in pull request #93: [MSHARED-993] Make uninstall resilient to Jansi errors
guylabs commented on a change in pull request #93:
URL: https://github.com/apache/maven-shared-utils/pull/93#discussion_r669298046
##
File path: src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java
##
@@ -98,7 +98,14 @@ private static void doSystemUninstall()
{
if ( JANSI )
{
-AnsiConsole.systemUninstall();
+try
+{
+AnsiConsole.systemUninstall();
+}
+catch ( RuntimeException ex )
Review comment:
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
[GitHub] [maven-jlink-plugin] dependabot[bot] opened a new pull request #64: Bump commons-io from 2.10.0 to 2.11.0
dependabot[bot] opened a new pull request #64: URL: https://github.com/apache/maven-jlink-plugin/pull/64 Bumps commons-io from 2.10.0 to 2.11.0. [](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) -- 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-converter] dependabot[bot] commented on pull request #13: Bump commons-io from 2.6 to 2.10.0
dependabot[bot] commented on pull request #13: URL: https://github.com/apache/maven-doxia-converter/pull/13#issuecomment-879567134 Superseded by #15. -- 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-converter] dependabot[bot] closed pull request #13: Bump commons-io from 2.6 to 2.10.0
dependabot[bot] closed pull request #13: URL: https://github.com/apache/maven-doxia-converter/pull/13 -- 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-converter] dependabot[bot] opened a new pull request #15: Bump commons-io from 2.6 to 2.11.0
dependabot[bot] opened a new pull request #15: URL: https://github.com/apache/maven-doxia-converter/pull/15 Bumps commons-io from 2.6 to 2.11.0. [](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) -- 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-javadoc-plugin] dependabot[bot] opened a new pull request #91: Bump commons-io from 2.8.0 to 2.11.0
dependabot[bot] opened a new pull request #91: URL: https://github.com/apache/maven-javadoc-plugin/pull/91 Bumps commons-io from 2.8.0 to 2.11.0. [](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) -- 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-javadoc-plugin] dependabot[bot] commented on pull request #84: Bump commons-io from 2.8.0 to 2.10.0
dependabot[bot] commented on pull request #84: URL: https://github.com/apache/maven-javadoc-plugin/pull/84#issuecomment-879550583 Superseded by #91. -- 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-javadoc-plugin] dependabot[bot] closed pull request #84: Bump commons-io from 2.8.0 to 2.10.0
dependabot[bot] closed pull request #84: URL: https://github.com/apache/maven-javadoc-plugin/pull/84 -- 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-shared-utils] elharo commented on a change in pull request #93: [MSHARED-993] Make uninstall resilient to Jansi errors
elharo commented on a change in pull request #93:
URL: https://github.com/apache/maven-shared-utils/pull/93#discussion_r669167357
##
File path: src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java
##
@@ -98,7 +98,14 @@ private static void doSystemUninstall()
{
if ( JANSI )
{
-AnsiConsole.systemUninstall();
+try
+{
+AnsiConsole.systemUninstall();
+}
+catch ( RuntimeException ex )
Review comment:
does it throw a specific runtime exception?
--
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-shared-utils] guylabs commented on pull request #93: [MSHARED-993] Make uninstall resilient to Jansi errors
guylabs commented on pull request #93: URL: https://github.com/apache/maven-shared-utils/pull/93#issuecomment-879445223 > We're still trying to fix this at JAnsi. This should only be accepted if JAnsi explcitly states they won't fix it. There are still no reactions to https://github.com/fusesource/jansi/issues/214. Not sure what the timeline is for the proper fix. Do you maybe have any other insights @rfscholte ? -- 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-1932) Periodic parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380193#comment-17380193
]
Tibor Digana commented on SUREFIRE-1932:
[~estratov]
See my answer in the Stackoverflow.
> Periodic parallel execution of tests
>
>
> Key: SUREFIRE-1932
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1932
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin, process forking
>Affects Versions: 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, 3.0.0-M4, 3.0.0-M5
>Reporter: EVGENII STRATOVICH
>Priority: Trivial
>
> For parallel testing is used next stack of technologies: java 8 (openjdk
> version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10),
> OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium,
> Selenide, Selenoid etc.
> From time to time during execution I encounter different problem associated
> with maven surefire. I perform parallel testing using Jenkins and jenkins
> file:
>
> {code:java}
> ('First suite'){
> parallel {
> stage('1 test'){
> }
> stage('2 test'){
> }
> }
> }
> {code}
> but periodically got error and failed stage due to failed test. Fragment of
> trace with error:
> {code:java}
> ExecutionException Error creating properties files for forking
> org.apache.maven.surefire.booter.SurefireBooterForkException:
> ExecutionException Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException:
> Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
[jira] [Closed] (SUREFIRE-1914) XML report omits method signature / display name of Junit 5 parameterized tests if testset reporter is configured to use phrased naming
[
https://issues.apache.org/jira/browse/SUREFIRE-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1914.
--
Fix Version/s: 3.0.0-M6
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=b09b721afc74b41925b7e2bffe3eedce6a50d9ed
> XML report omits method signature / display name of Junit 5 parameterized
> tests if testset reporter is configured to use phrased naming
> ---
>
> Key: SUREFIRE-1914
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1914
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, xml generation
>Affects Versions: 3.0.0-M5
>Reporter: Andreas Pabst
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> h3. Description of the issue
> Given a test class with two parameterized tests as follows:
> {code:java}
> @ParameterizedTest
> @ValueSource(strings = {"a", "b"})
> void test1(String param) {
> // test code
> }
> @ParameterizedTest
> @ValueSource(strings = {"a", "b"})
> void test2(String param) {
> // test code
> }
> {code}
> and a surefire configuration that includes the following:
> {code:xml}
> implementation="org.apache.maven.plugin.surefire.extensions.junit5.JUnit5Xml30StatelessReporter">
> 3.0
> true
> true
> true
>
> {code}
> the XML report will look like this:
> {code:xml}
>
>
>
>
> {code}
> Note: The test method name/signature is not included in the name attribute.
> I would expect something more like this:
> {code:xml}
>time="0.001" />
>time="0.001" />
>time="0.001" />
>time="0.001" />
> {code}
> h3. Some context on why this is bad
> Omitting the test method name makes it impossible to differentiate individual
> test cases in the XML report if there are multiple
> {{@ParameterizedTest}}-annotated test cases in the same class that use the
> same parameters.
> Any software that parses the surefire XML reports will be misled into
> thinking these are multiple executions of the same test.
> h3. Variant with {{@DisplayName}} usage
> There is a variant of this issue: If the {{@ParameterizedTest}} has a
> {{@DisplayName}} annotation, whatever was chosen as a display name is not
> included in the XML report either - unless it is explicitly referenced in the
> name attribute of the {{@ParameterizedTest}} like so:
> {{@ParameterizedTest(name = "\{displayName} ...")}}.
> h3. Solution ideas
> This issue has already been brought up during the discussion of SUREFIRE-1546.
> In that discussion [~srdo] and [~marcphilipp] have described an approach how
> CONTAINER-type TestIdentifiers could be handled properly, but that particular
> problem seems to have been deferred and has seemingly not been picked up
> again since.
> h3. Workaround
> A workaround is to explicitly reference the displayName or include some other
> unique string in the name attribute of each {{@ParameterizedTest}} as
> mentioned above. In projects with a large legacy testbase that might not be
> feasible though, so this issue might prevent the adoption of the feature
> introduced in SUREFIRE-1546.
> I'm submitting this as a bug because to me the current behaviour of surefire
> is at least unexpected, but it could also be seen as a request for
> improvement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SUREFIRE-1914) XML report omits method signature / display name of Junit 5 parameterized tests if testset reporter is configured to use phrased naming
[
https://issues.apache.org/jira/browse/SUREFIRE-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1914:
--
Assignee: Tibor Digana
> XML report omits method signature / display name of Junit 5 parameterized
> tests if testset reporter is configured to use phrased naming
> ---
>
> Key: SUREFIRE-1914
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1914
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, xml generation
>Affects Versions: 3.0.0-M5
>Reporter: Andreas Pabst
>Assignee: Tibor Digana
>Priority: Major
>
> h3. Description of the issue
> Given a test class with two parameterized tests as follows:
> {code:java}
> @ParameterizedTest
> @ValueSource(strings = {"a", "b"})
> void test1(String param) {
> // test code
> }
> @ParameterizedTest
> @ValueSource(strings = {"a", "b"})
> void test2(String param) {
> // test code
> }
> {code}
> and a surefire configuration that includes the following:
> {code:xml}
> implementation="org.apache.maven.plugin.surefire.extensions.junit5.JUnit5Xml30StatelessReporter">
> 3.0
> true
> true
> true
>
> {code}
> the XML report will look like this:
> {code:xml}
>
>
>
>
> {code}
> Note: The test method name/signature is not included in the name attribute.
> I would expect something more like this:
> {code:xml}
>time="0.001" />
>time="0.001" />
>time="0.001" />
>time="0.001" />
> {code}
> h3. Some context on why this is bad
> Omitting the test method name makes it impossible to differentiate individual
> test cases in the XML report if there are multiple
> {{@ParameterizedTest}}-annotated test cases in the same class that use the
> same parameters.
> Any software that parses the surefire XML reports will be misled into
> thinking these are multiple executions of the same test.
> h3. Variant with {{@DisplayName}} usage
> There is a variant of this issue: If the {{@ParameterizedTest}} has a
> {{@DisplayName}} annotation, whatever was chosen as a display name is not
> included in the XML report either - unless it is explicitly referenced in the
> name attribute of the {{@ParameterizedTest}} like so:
> {{@ParameterizedTest(name = "\{displayName} ...")}}.
> h3. Solution ideas
> This issue has already been brought up during the discussion of SUREFIRE-1546.
> In that discussion [~srdo] and [~marcphilipp] have described an approach how
> CONTAINER-type TestIdentifiers could be handled properly, but that particular
> problem seems to have been deferred and has seemingly not been picked up
> again since.
> h3. Workaround
> A workaround is to explicitly reference the displayName or include some other
> unique string in the name attribute of each {{@ParameterizedTest}} as
> mentioned above. In projects with a large legacy testbase that might not be
> feasible though, so this issue might prevent the adoption of the feature
> introduced in SUREFIRE-1546.
> I'm submitting this as a bug because to me the current behaviour of surefire
> is at least unexpected, but it could also be seen as a request for
> improvement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #352: [SUREFIRE-1914] Take displayName of container into account for XML reporting of @ParameterizedTest
Tibor17 commented on pull request #352: URL: https://github.com/apache/maven-surefire/pull/352#issuecomment-879424513 @andpab Thx for contributing! -- 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] Tibor17 merged pull request #352: [SUREFIRE-1914] Take displayName of container into account for XML reporting of @ParameterizedTest
Tibor17 merged pull request #352: URL: https://github.com/apache/maven-surefire/pull/352 -- 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-shared-utils] guylabs commented on a change in pull request #93: [MSHARED-993] Make uninstall resilient to Jansi errors
guylabs commented on a change in pull request #93:
URL: https://github.com/apache/maven-shared-utils/pull/93#discussion_r669131813
##
File path: src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java
##
@@ -98,7 +98,14 @@ private static void doSystemUninstall()
{
if ( JANSI )
{
-AnsiConsole.systemUninstall();
+try
+{
+AnsiConsole.systemUninstall();
+}
+catch ( Throwable ex )
Review comment:
Thanks! Fixed.
--
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-resolver] michael-o closed pull request #48: [MRESOLVER-103] replace some deprecated classes
michael-o closed pull request #48: URL: https://github.com/apache/maven-resolver/pull/48 -- 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] Tibor17 commented on pull request #352: [SUREFIRE-1914] Take displayName of container into account for XML reporting of @ParameterizedTest
Tibor17 commented on pull request #352: URL: https://github.com/apache/maven-surefire/pull/352#issuecomment-879378082 @andpab yes I see, now the CI is running. Let's wait 2 hours for the outcome. -- 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] andpab commented on pull request #352: [SUREFIRE-1914] Take displayName of container into account for XML reporting of @ParameterizedTest
andpab commented on pull request #352: URL: https://github.com/apache/maven-surefire/pull/352#issuecomment-879374942 Rebased to upstream master and squashed the two commits. -- 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] Tibor17 closed pull request #351: [SUREFIRE-1914] Draft: Document expected XML report format for @ParameterizedTest with ITs
Tibor17 closed pull request #351: URL: https://github.com/apache/maven-surefire/pull/351 -- 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-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380109#comment-17380109
]
Nils Breunese commented on MNG-7185:
I've created a pull request to update the Javadoc:
https://github.com/apache/maven/pull/487
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] breun opened a new pull request #487: [MNG-7185] - Describe explicit and recommended version for VersionRange.createFromVersionSpec
breun opened a new pull request #487: URL: https://github.com/apache/maven/pull/487 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/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-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 verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [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). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-7185:
Fix Version/s: (was: waiting-for-feedback)
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-7185:
Summary: Describe explicit and recommended version for
VersionRange.createFromVersionSpec (was: Single version range should not match
other versions)
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-7185:
Issue Type: Improvement (was: Bug)
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380042#comment-17380042
]
Robert Scholte commented on MNG-7185:
-
I'll rename this ticket.
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-enforcer] dependabot[bot] opened a new pull request #98: Bump maven-resolver-util from 1.6.1 to 1.7.1
dependabot[bot] opened a new pull request #98: URL: https://github.com/apache/maven-enforcer/pull/98 Bumps [maven-resolver-util](https://github.com/apache/maven-resolver) from 1.6.1 to 1.7.1. Commits https://github.com/apache/maven-resolver/commit/f35e01817ad19ff5aef9733170461b71b68b2ac1";>f35e018 [maven-release-plugin] prepare release maven-resolver-1.7.1 https://github.com/apache/maven-resolver/commit/1aba84cebf146c5dce9dc4209a0581b88d5a78e1";>1aba84c [MRESOLVER-186] Update Maven version in Resolver Demo Snippets https://github.com/apache/maven-resolver/commit/69fd9f38d75fe5fd62c3a6b8d70b1018b67f7a68";>69fd9f3 [MRESOLVER-184] Destroy Redisson semaphores if not used anymore https://github.com/apache/maven-resolver/commit/c256c20b77fd1f1ed512c79ef3de0b81b3b5ccb4";>c256c20 [MRESOLVER-185] Upgrade Redisson to 3.15.6 https://github.com/apache/maven-resolver/commit/6addf396749e3cc242bb5a25cf47d405850a1afa";>6addf39 [MRESOLVER-183] Don't require optional dependencies for Redisson https://github.com/apache/maven-resolver/commit/5d4e3473164a6909b7035d6a16acad3a69aa1402";>5d4e347 Fix checkstyle https://github.com/apache/maven-resolver/commit/45e243b62bc4a1a08243dfeddd8abe4cd0ed467b";>45e243b Use static instead of literal https://github.com/apache/maven-resolver/commit/0b13e57f9226a16e049dfc38f2a5b1df76a1ceee";>0b13e57 Update workflow https://github.com/apache/maven-resolver/commit/a7d1bf9a94f14bda4f118f95cdb8d280d7ec2c62";>a7d1bf9 Use interface instead of impl https://github.com/apache/maven-resolver/commit/f9169478bfcb4586e939619efd01d07221f52e7a";>f916947 Sort dependencies by JAR name Additional commits viewable in https://github.com/apache/maven-resolver/compare/maven-resolver-1.6.1...maven-resolver-1.7.1";>compare view [](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) -- 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-enforcer] asfgit closed pull request #69: enable Dependabot v2
asfgit closed pull request #69: URL: https://github.com/apache/maven-enforcer/pull/69 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379965#comment-17379965
]
Nils Breunese commented on MNG-7185:
Thanks for the explanation. I guess the conclusion is that there is no bug, but
Javadoc for {{VersionRange#createFromVersionSpec}} doesn't show the syntax for
a closed range for a single version.
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
[ https://issues.apache.org/jira/browse/MENFORCER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379960#comment-17379960 ] Hudson commented on MENFORCER-376: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-enforcer » master #69 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/69/ > Add support for excludes/includes in requireJavaVendor rule > --- > > Key: MENFORCER-376 > URL: https://issues.apache.org/jira/browse/MENFORCER-376 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > > There was a suggestion here [1] to add includes/excludes support in > requireJavaVendor rule. Right now it's not clear how it would work if you > define the same vendor name in exclude and include lists but implementation > can be more or less copied from BannedDependencies rule. > [1] > https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1932) Periodic parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379955#comment-17379955
]
EVGENII STRATOVICH commented on SUREFIRE-1932:
--
Attach fragment of pom.xml:
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M5
org.aspectj
aspectjweaver
${aspectj.version}
${project.build.outputDirectory}
false
0
true
-Xmx1024m -XX:MaxPermSize=256m
{code}
> Periodic parallel execution of tests
>
>
> Key: SUREFIRE-1932
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1932
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin, process forking
>Affects Versions: 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, 3.0.0-M4, 3.0.0-M5
>Reporter: EVGENII STRATOVICH
>Priority: Trivial
>
> For parallel testing is used next stack of technologies: java 8 (openjdk
> version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10),
> OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium,
> Selenide, Selenoid etc.
> From time to time during execution I encounter different problem associated
> with maven surefire. I perform parallel testing using Jenkins and jenkins
> file:
>
> {code:java}
> ('First suite'){
> parallel {
> stage('1 test'){
> }
> stage('2 test'){
> }
> }
> }
> {code}
> but periodically got error and failed stage due to failed test. Fragment of
> trace with error:
> {code:java}
> ExecutionException Error creating properties files for forking
> org.apache.maven.surefire.booter.SurefireBooterForkException:
> ExecutionException Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException:
> Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
> at
> org.apache.maven.plugin.surefire.b
[GitHub] [maven-enforcer] rfscholte commented on pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
rfscholte commented on pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86#issuecomment-879169611 This PR was the base for https://github.com/apache/maven-enforcer/commit/3b47fa9627bdf96a9fb45aac31c655bc6cae5060 -- 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-enforcer] rfscholte closed pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
rfscholte closed pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86 -- 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] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
[ https://issues.apache.org/jira/browse/MENFORCER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MENFORCER-376. Fix Version/s: 3.0.0 Resolution: Fixed Fixed in [3b47fa9627bdf96a9fb45aac31c655bc6cae5060|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commit;h=3b47fa9627bdf96a9fb45aac31c655bc6cae5060] > Add support for excludes/includes in requireJavaVendor rule > --- > > Key: MENFORCER-376 > URL: https://issues.apache.org/jira/browse/MENFORCER-376 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > > There was a suggestion here [1] to add includes/excludes support in > requireJavaVendor rule. Right now it's not clear how it would work if you > define the same vendor name in exclude and include lists but implementation > can be more or less copied from BannedDependencies rule. > [1] > https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1932) Periodic parallel execution of tests
EVGENII STRATOVICH created SUREFIRE-1932:
Summary: Periodic parallel execution of tests
Key: SUREFIRE-1932
URL: https://issues.apache.org/jira/browse/SUREFIRE-1932
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Surefire Plugin, process forking
Affects Versions: 3.0.0-M5, 3.0.0-M4, 3.0.0-M3, 3.0.0-M1, 3.0.0-M2
Reporter: EVGENII STRATOVICH
For parallel testing is used next stack of technologies: java 8 (openjdk
version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10), OpenJDK
64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium, Selenide,
Selenoid etc.
>From time to time during execution I encounter different problem associated
>with maven surefire. I perform parallel testing using Jenkins and jenkins file:
{code:java}
('First suite'){
parallel {
stage('1 test'){
}
stage('2 test'){
}
}
}
{code}
but periodically got error and failed stage due to failed test. Fragment of
trace with error:
{code:java}
ExecutionException Error creating properties files for forking
org.apache.maven.surefire.booter.SurefireBooterForkException:
ExecutionException Error creating properties files for forking at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error
creating properties files for forking at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: No
such file or directory at java.io.UnixFileSystem.createFileExclusively(Native
Method) at java.io.File.createTempFile(File.java:2063) at
org.apache.maven.surefire.booter.SystemPropertyManager.writePropertiesFile(SystemPropertyManager.java:77)
at
org.apache.maven.plugin.surefire.boot
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379949#comment-17379949
]
Robert Scholte commented on MNG-7185:
-
Let's say you write a library. You add a dependency called 'utils' with a
recommended version, so without bounderies. At compile time this will be the
version to be used.
Now there's an application that wants to use this library, but it also adds
utils with a different version. This is fine, because the library only
specified a recommended version. In case library gave utils a version with
bounderies, the application can only choose a version for utils that fits
within the specified bounderies.
If 'library' specified {{[1.0.0]}} for utils, that's the only allowed version,
application cannot change it.
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] mbenson commented on pull request #66: Archetype 618
mbenson commented on pull request #66: URL: https://github.com/apache/maven-archetype/pull/66#issuecomment-879150147 @elharo Sorry to drag you into this, but the last PR was lacking and this one improves upon it. I'd hate for a solution with known problems to make it into a release. -- 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-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379926#comment-17379926
]
Nils Breunese commented on MNG-7185:
I don't really grasp the concept of a version range representing a recommended
version (what is that used for?), but it looks like {{[1.0.0]}} is the syntax I
actually wanted to use. This syntax is not mentioned in the Javadoc of
{{VersionRange#createFromVersionSpec}}, so that might be a good idea to add?
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MENFORCER-267) Upgrade to make Maven 3.1+
[ https://issues.apache.org/jira/browse/MENFORCER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MENFORCER-267. Assignee: Robert Scholte Resolution: Fixed I consider this solved as part of MENFORCER-277 > Upgrade to make Maven 3.1+ > -- > > Key: MENFORCER-267 > URL: https://issues.apache.org/jira/browse/MENFORCER-267 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M3 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0, 3.0.0-M4 > > > * maven-dependency-tree needs to be updated to 3.0.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-277) Upgrade maven-dependency-tree to 3.x
[
https://issues.apache.org/jira/browse/MENFORCER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379893#comment-17379893
]
Hudson commented on MENFORCER-277:
--
Build succeeded in Jenkins: Maven » Maven TLP » maven-enforcer » master #67
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/67/
> Upgrade maven-dependency-tree to 3.x
>
>
> Key: MENFORCER-277
> URL: https://issues.apache.org/jira/browse/MENFORCER-277
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: S2
> Fix For: 3.0.0
>
> Attachments: MENFORCER-277.patch
>
>
> As part of MENFORCER-264 maven-dependency-tree should be upgraded. This would
> imply switching from the M2 {{DependencyTreeBuilder}} to M2/M3
> {{DependencyGraphBuilder}}.
> However, {{DependencyGraphBuilder}} uses {{ProjectDependenciesResolver}},
> which provides the *resolved* graph instead of a raw tree.
> This is a requirement for both {{DependencyConvergence}} and
> {{RequireUpperBoundDeps}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MENFORCER-387) Require Java 8
[ https://issues.apache.org/jira/browse/MENFORCER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MENFORCER-387: - Comment: was deleted (was: Build failed in Jenkins: Maven » Maven TLP » maven-enforcer » master #65 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/65/) > Require Java 8 > -- > > Key: MENFORCER-387 > URL: https://issues.apache.org/jira/browse/MENFORCER-387 > Project: Maven Enforcer Plugin > Issue Type: Task >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > > Maven Dependency Tree 3.1.0 requires Java 8, so a good reason to increase > this requirement for the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-277) Upgrade maven-dependency-tree to 3.x
[
https://issues.apache.org/jira/browse/MENFORCER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-277.
Assignee: Robert Scholte
Resolution: Fixed
Fixed in
[ca40308fd58c45e638a35768b3966b5680d4c60e|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commit;h=ca40308fd58c45e638a35768b3966b5680d4c60e]
> Upgrade maven-dependency-tree to 3.x
>
>
> Key: MENFORCER-277
> URL: https://issues.apache.org/jira/browse/MENFORCER-277
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: S2
> Fix For: 3.0.0
>
> Attachments: MENFORCER-277.patch
>
>
> As part of MENFORCER-264 maven-dependency-tree should be upgraded. This would
> imply switching from the M2 {{DependencyTreeBuilder}} to M2/M3
> {{DependencyGraphBuilder}}.
> However, {{DependencyGraphBuilder}} uses {{ProjectDependenciesResolver}},
> which provides the *resolved* graph instead of a raw tree.
> This is a requirement for both {{DependencyConvergence}} and
> {{RequireUpperBoundDeps}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-189) Using semaphore-redisson followed by rwlock-redisson on many parallel build of the same project triggers redisson error
[
https://issues.apache.org/jira/browse/MRESOLVER-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379883#comment-17379883
]
Jacques-Etienne Beaudet commented on MRESOLVER-189:
---
I've sent you via email the logs of the failures for the rwlock-gav based off
the tip of the 3.8 branch (f32c3dba9495e3b7d4a73de6d303ae2eedb769f5) with
resolver 1.7.1.
> Using semaphore-redisson followed by rwlock-redisson on many parallel build
> of the same project triggers redisson error
> ---
>
> Key: MRESOLVER-189
> URL: https://issues.apache.org/jira/browse/MRESOLVER-189
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Jacques-Etienne Beaudet
>Assignee: Michael Osipov
>Priority: Major
> Attachments: create_lock_events.sql, etl.sql, logs-data.zip,
> schema.sql
>
>
> While testing performance for in
> [https://github.com/apache/maven-resolver/pull/68|https://github.com/apache/maven-resolver/pull/68]
> , I ran into an error using rwlock-redisson. Here are the steps to reproduce
> (hopefully it's easily reproducible on your end) and the logs of the run
> (trace enabled on org.eclipse.aether) at the end :
> * `redis-cli flushall` to get a clean slate
> * Clone a repository with a fair size
> * Make 4 copy of this repository (I ran my test with 4 copies, but 2 might
> be enough?)
> * `mvn clean` on all repositories
> * run a parallel build with semaphore-redis (`mvn compile -T1C
> -Daether.syncContext.named.factory=semaphore-redisson`) on all repositories
> * `mvn clean` all repositories
> * run a parallel build with rwlock-redis (`mvn compile -T1C
> -Daether.syncContext.named.factory=rwlock-redisson`) on all repositories
> By doing this, I ran into this and the only way out was running a `redis-cli
> flushall`.
>
> The way I ran my parallel build was really dumb and simple, something like
> that :
>
> {code:java}
> cd repo1 ; mvn clean > /tmp/log1 2>&1 & cd ../repo2 ; mvn clean > /tmp/log2
> 2>&1 & cd ../repo3 ; mvn clean > /tmp/log3 2>&1 & cd ../repo4 ; mvn clean >
> /tmp/log4 2>&1 & cd .. ;
> {code}
>
>
> Let me know if you can't reproduce, I might be able to provide you with
> traces logs of the semaphore build as well.
> {code:java}
> [INFO] Redisson 3.15.6
> [INFO] 1 connections initialized for localhost/127.0.0.1:6379
> [INFO] 24 connections initialized for localhost/127.0.0.1:6379
> [TRACE] Created Redisson client with id '42934566-3759-4f73-9fbc-a2d0a8368e1f'
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> /root/.m2/repository
> [INFO] Scanning for projects...
> [TRACE] Need 1 write lock(s) for
> [artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0]
> [TRACE] Acquiring write lock for
> 'artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0'
> [ERROR] Internal error: org.redisson.client.RedisException: ERR Error running
> script (call to f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1:
> WRONGTYPE Operation against a key holding the wrong kind of value. channel:
> [id: 0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command:
> (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode
> == false) then redis.call('hset', KEYS[1]..., 1,
> maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0,
> 3, 42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write] -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> org.redisson.client.RedisException: ERR Error running script (call to
> f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1: WRONGTYPE
> Operation against a key holding the wrong kind of value. channel: [id:
> 0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command: (EVAL),
> params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false)
> then redis.call('hset', KEYS[1]..., 1,
> maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0,
> 3, 42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write]
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
>
[GitHub] [maven-antrun-plugin] dependabot[bot] opened a new pull request #21: Bump ant from 1.10.10 to 1.10.11
dependabot[bot] opened a new pull request #21: URL: https://github.com/apache/maven-antrun-plugin/pull/21 Bumps ant from 1.10.10 to 1.10.11. [](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) -- 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-shared-utils] elharo commented on a change in pull request #93: [MSHARED-993] Make uninstall resilient to Jansi errors
elharo commented on a change in pull request #93:
URL: https://github.com/apache/maven-shared-utils/pull/93#discussion_r668738184
##
File path: src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java
##
@@ -98,7 +98,14 @@ private static void doSystemUninstall()
{
if ( JANSI )
{
-AnsiConsole.systemUninstall();
+try
+{
+AnsiConsole.systemUninstall();
+}
+catch ( Throwable ex )
Review comment:
never catch Throwable. See Effective Java for reasons.
--
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-dependency-analyzer] elharo merged pull request #38: Bump asm from 9.1 to 9.2
elharo merged pull request #38: URL: https://github.com/apache/maven-dependency-analyzer/pull/38 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-189) Using semaphore-redisson followed by rwlock-redisson on many parallel build of the same project triggers redisson error
[
https://issues.apache.org/jira/browse/MRESOLVER-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Etienne Beaudet updated MRESOLVER-189:
--
Description:
While testing performance for in
[https://github.com/apache/maven-resolver/pull/68|https://github.com/apache/maven-resolver/pull/68]
, I ran into an error using rwlock-redisson. Here are the steps to reproduce
(hopefully it's easily reproducible on your end) and the logs of the run (trace
enabled on org.eclipse.aether) at the end :
* `redis-cli flushall` to get a clean slate
* Clone a repository with a fair size
* Make 4 copy of this repository (I ran my test with 4 copies, but 2 might be
enough?)
* `mvn clean` on all repositories
* run a parallel build with semaphore-redis (`mvn compile -T1C
-Daether.syncContext.named.factory=semaphore-redisson`) on all repositories
* `mvn clean` all repositories
* run a parallel build with rwlock-redis (`mvn compile -T1C
-Daether.syncContext.named.factory=rwlock-redisson`) on all repositories
By doing this, I ran into this and the only way out was running a `redis-cli
flushall`.
The way I ran my parallel build was really dumb and simple, something like that
:
{code:java}
cd repo1 ; mvn clean > /tmp/log1 2>&1 & cd ../repo2 ; mvn clean > /tmp/log2
2>&1 & cd ../repo3 ; mvn clean > /tmp/log3 2>&1 & cd ../repo4 ; mvn clean >
/tmp/log4 2>&1 & cd .. ;
{code}
Let me know if you can't reproduce, I might be able to provide you with traces
logs of the semaphore build as well.
{code:java}
[INFO] Redisson 3.15.6
[INFO] 1 connections initialized for localhost/127.0.0.1:6379
[INFO] 24 connections initialized for localhost/127.0.0.1:6379
[TRACE] Created Redisson client with id '42934566-3759-4f73-9fbc-a2d0a8368e1f'
[DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
/root/.m2/repository
[INFO] Scanning for projects...
[TRACE] Need 1 write lock(s) for
[artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0]
[TRACE] Acquiring write lock for
'artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0'
[ERROR] Internal error: org.redisson.client.RedisException: ERR Error running
script (call to f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1:
WRONGTYPE Operation against a key holding the wrong kind of value. channel:
[id: 0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command:
(EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode ==
false) then redis.call('hset', KEYS[1]..., 1,
maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0, 3,
42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write] -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
org.redisson.client.RedisException: ERR Error running script (call to
f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1: WRONGTYPE
Operation against a key holding the wrong kind of value. channel: [id:
0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command: (EVAL),
params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false)
then redis.call('hset', KEYS[1]..., 1,
maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0, 3,
42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write]
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: org.redisson.client.RedisException: ERR Error running script (call
to f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1: WRONGTYPE
Operation against a key holding the wrong kind of value. channel: [id:
0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command: (EVAL),
params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false)
then redis.call('hset', KEYS[1]..., 1,
maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0, 3,
42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write]
at org.redisson.client.handler.CommandDecoder.decode
(CommandDecoder.java:345)
at org.redisson.client.handler.CommandDecoder.decodeCommandBatch
(CommandDecod
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379827#comment-17379827 ] Hudson commented on MNG-6754: - Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #49 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/49/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] michael-o merged pull request #147: Fix source repo link
michael-o merged pull request #147: URL: https://github.com/apache/maven-dependency-plugin/pull/147 -- 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-dependency-plugin] eNeRGy164 opened a new pull request #147: Fix source repo link
eNeRGy164 opened a new pull request #147: URL: https://github.com/apache/maven-dependency-plugin/pull/147 The link to _source repository_ points to a non-existing page. Modified the link to the appropriate page. - [x] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- 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] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6241:
---
Assignee: (was: Michael Osipov)
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6241:
Fix Version/s: (was: 3.8.x-candidate)
(was: 4.0.x-candidate)
wontfix-candidate
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Assignee: Michael Osipov
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6754: Fix Version/s: 3.8.2 > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[
https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379716#comment-17379716
]
Michael Osipov commented on MNG-6754:
-
Fixed with
[a3907fcb2b541d80852611b68494965f10b828f2|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=a3907fcb2b541d80852611b68494965f10b828f2]
for {{maven-3.8.x}} branch.
> Set the same timestamp in multi module builds
> -
>
> Key: MNG-6754
> URL: https://issues.apache.org/jira/browse/MNG-6754
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, Deployment
>Affects Versions: 3.6.3
>Reporter: Michael Angstadt
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> When multi module snapshots are built using Maven, the version timestamp may
> be different for each module. This makes it difficult to quickly reference a
> historical snapshot of a multi module project, which is something we might do
> when determining when a bug was introduced.
> [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802]
> provides a good example of the problem. [The accepted
> answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable
> solution, but does not appear to work. [Looking at the
> code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85],
> there does not appear to be a way to override the timestamp.
> Please add a way to use a consistent timestamp for all modules in a build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-26) add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module names
[
https://issues.apache.org/jira/browse/MRESOLVER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379707#comment-17379707
]
Michael Osipov commented on MRESOLVER-26:
-
[~hboutemy], there is still branch
{{MRESOLVER-26_AutomaticModuleNameImprovements}}, can it be safely dropped?
> add Automatic-Module-Name entry to MANIFEST.MF for Java 9 automatic module
> names
>
>
> Key: MRESOLVER-26
> URL: https://issues.apache.org/jira/browse/MRESOLVER-26
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: Maven Artifact Resolver 1.1.0
>
>
> as discussed in dev ML:
> https://lists.apache.org/thread.html/6853f497ea01a00906bee6d9e7d32c39cc40f3c1b8ca6fad706e3888@%3Cdev.maven.apache.org%3E
> Java 9 with Jigsaw modules is coming
> Maven Artifact Resolver:
> # has a chance to be turned into Java 9 modules
> # could be useful as Java 9 modules
> starting by just defining Automatic Modules Names is a quickstart
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379690#comment-17379690
]
Robert Scholte commented on MNG-7185:
-
Indeed, if it is just a recommended value. It doesn't represent a range, so
{{containsVersion}} will always return {{true}}.
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
