[jira] [Commented] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516672#comment-17516672
]
Marc Schlegel commented on SUREFIRE-2053:
-
Currently no fork mode is enabled. I did some tests with forkCount/reuseForks
(since forkMode is deprecated) without success.
So, when the surefire booter is definately using another JVM then why is it not
considering .mvn/jvm.config?
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516686#comment-17516686
]
Michael Osipov commented on SUREFIRE-2053:
--
{{.mvn/jvm.config}} applies to the Maven JVM only, nothing else. It would be a
clear violation of separation of concerns mixing both. [~tibordigana].
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516699#comment-17516699
]
Marc Schlegel commented on SUREFIRE-2053:
-
If thats the reason I am fine with it, but please consider updating the
[documentation|https://maven.apache.org/configure.html] stating that this has
no effect on `surefire` and I guess also on `failsafe`
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516700#comment-17516700
]
Nathan McDonald commented on SUREFIRE-2029:
---
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.{noformat}
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> A
[jira] [Comment Edited] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516699#comment-17516699
]
Marc Schlegel edited comment on SUREFIRE-2053 at 4/4/22 9:08 AM:
-
If thats the reason I am fine with it, but please consider updating the
[documentation|https://maven.apache.org/configure.html] stating that this has
no effect on surefire and I guess also on failsafe.
I was rellying on that documentation and spent quite some time with it because
I thought I've done a typo or something similar.
was (Author: JIRAUSER287466):
If thats the reason I am fine with it, but please consider updating the
[documentation|https://maven.apache.org/configure.html] stating that this has
no effect on `surefire` and I guess also on `failsafe`
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516700#comment-17516700
]
Nathan McDonald edited comment on SUREFIRE-2029 at 4/4/22 9:08 AM:
---
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{code:java}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.{code:java}
was (Author: JIRAUSER286028):
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.{noformat}
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all ot
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516700#comment-17516700
]
Nathan McDonald edited comment on SUREFIRE-2029 at 4/4/22 9:09 AM:
---
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{quote}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.{quote}
was (Author: JIRAUSER286028):
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{code:java}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.{code:java}
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other su
[jira] [Comment Edited] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516700#comment-17516700
]
Nathan McDonald edited comment on SUREFIRE-2029 at 4/4/22 9:10 AM:
---
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
was (Author: JIRAUSER286028):
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{quote}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.{quote}
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:ja
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516705#comment-17516705
]
Falko Modler commented on SUREFIRE-2029:
{quote}If you use parallel Maven build, i.e. -T... , the forkNumbers may
repeat.{quote}
A mere _repetition_ during the course of an entire multi-module build is not a
problem for me, but that you can end up with the same number in two
_concurrently_ running modules/test JVM forks is what bothers me/us.
> Parallel execution but surefire.forkNumber is the same
> --
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.2
>Reporter: Nathan McDonald
>Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/apache-maven
> Java version: 11.0.13, vendor: Red Hat, Inc., runtime:
> /u
[jira] [Commented] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516713#comment-17516713
]
Michael Osipov commented on SUREFIRE-2053:
--
Feel free to raise a PR, but I think we should not list where it does *not*
apply because this is Maven only, and Surefire isn't Maven Core. I assume that
https://maven.apache.org/configure.html#mvn-jvm-config-file isn't good enough
in this case. It must mention that it is Maven only.
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516719#comment-17516719
]
Marc Schlegel commented on SUREFIRE-2053:
-
Feel free to close then (I cant).
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2053) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/SUREFIRE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-2053.
Resolution: Information Provided
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: SUREFIRE-2053
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2053
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Marc Schlegel
>Priority: Major
>
> We are on the way upgrading to Java 17 and since 17 does not allow unopened
> access anymore we have to pass several add-open JVM settings.
> Following [this|https://maven.apache.org/configure.html] documentation, we've
> setup the needed instructions.
> {code:java}
> --add-opens java.base/java.lang=ALL-UNNAMED
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.time=ALL-UNNAMED
> {code}
> We currently see two cases where add-opens is needed:
> * jqassistant-plugin
> * OpenPojo Library during test-phase
> The jqassistant-plugin works fine with this settings (and fails without),
> though the surefire-plugin is not passing the jvm-options (or maven-core is
> not passing it to surefire).
> This is the error which OpenPojo receives:
> {code:java}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private static final long java.time.LocalDate.serialVersionUID
> accessible: module java.base does not "opens java.time" to unnamed module
> @48a242ce {code}
> As a workaround I have to configure surefire via argLine in addition to
> jvm.options
> {code:java}
>
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
>
> --add-opens java.base/java.time=ALL-UNNAMED
>
> ${skipUTs}
>
>
> org.jboss.logmanager.LogManager
>
>
>
> **/*Test.java
> **/*Spec.java
>
>
> {code}
> This should not be necessary. It should be enough to configure jvm specific
> settings for Maven in one place.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-2056) BufferOverflowException when logging message with null testId
Yoann Rodière created SUREFIRE-2056:
---
Summary: BufferOverflowException when logging message with null
testId
Key: SUREFIRE-2056
URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M6
Reporter: Yoann Rodière
The problem seems to have been introduced here:
https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
{code}
int bufferMaxLength = estimateBufferLength(
eventType.getOpcode().length(), runMode, encoder, 0,
testRunId == null ? 0 : 1, message );
{code}
The buffer estimate seems to ignore the testRunId field completely when the
testRunId is null, but the {{encodeHeader}} method still adds content to the
buffer even when the testRunId is null, resulting in a buffer overflow:
https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
{code}
result.put( (byte) ( testRunId == null ? 0 : 1 ) );
if ( testRunId != null )
{
result.putLong( testRunId );
}
result.put( (byte) ':' );
{code}
Sending a PR shortly.
Stack trace:
{noformat}
java.lang.IllegalStateException: Failed to load ApplicationContext
at
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
at
org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
at
org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
[jira] [Updated] (SUREFIRE-2056) BufferOverflowException when encoding message with null testId
[
https://issues.apache.org/jira/browse/SUREFIRE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoann Rodière updated SUREFIRE-2056:
Summary: BufferOverflowException when encoding message with null testId
(was: BufferOverflowException when logging message with null testId)
> BufferOverflowException when encoding message with null testId
> --
>
> Key: SUREFIRE-2056
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Yoann Rodière
>Priority: Major
>
> The problem seems to have been introduced here:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
> {code}
> int bufferMaxLength = estimateBufferLength(
> eventType.getOpcode().length(), runMode, encoder, 0,
> testRunId == null ? 0 : 1, message );
> {code}
> The buffer estimate seems to ignore the testRunId field completely when the
> testRunId is null, but the {{encodeHeader}} method still adds content to the
> buffer even when the testRunId is null, resulting in a buffer overflow:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
> {code}
> result.put( (byte) ( testRunId == null ? 0 : 1 ) );
> if ( testRunId != null )
> {
> result.putLong( testRunId );
> }
> result.put( (byte) ':' );
> {code}
> Sending a PR shortly.
> Stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
> at
> org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at
> org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
> at
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.jun
[GitHub] [maven-surefire] yrodiere opened a new pull request, #506: SUREFIRE-2056 BufferOverflowException when encoding message with null testId
yrodiere opened a new pull request, #506: URL: https://github.com/apache/maven-surefire/pull/506 See https://issues.apache.org/jira/browse/SUREFIRE-2056 for an analysis of the problem. This brings the buffer size back in line with what `encodeHeader` actually does, thereby avoiding a buffer overflow. - - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] kwin commented on pull request #706: [MNG-7432] Proposed UT for maven-3.9.x and 3.8.x
kwin commented on PR #706: URL: https://github.com/apache/maven/pull/706#issuecomment-1087441097 Just take over the UT to your branch and then this PR can be closed. That makes it easier to commit to 3.9/3.8.x. -- 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-mvnd] orpiske commented on issue #337: Add Apple M1 build.
orpiske commented on issue #337: URL: https://github.com/apache/maven-mvnd/issues/337#issuecomment-1087450339 I know support is not official yet, but sharing my experience in the hope it will eventually be useful for when there is an official release. One thing I noticed is that the build for ARM doesn't seem to respect the `mvnd.threads` setting or the -T flag. Using -T 0.5C here, still causes it to use all cores. https://user-images.githubusercontent.com/1851560/161536224-fb308057-8568-4e12-95f1-7980de60f916.png";> -- 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] cstamas commented on pull request #706: [MNG-7432] Proposed UT for maven-3.9.x and 3.8.x
cstamas commented on PR #706: URL: https://github.com/apache/maven/pull/706#issuecomment-1087450988 Yes please, just lift it. Am currently a bit overwhelmed with $other work, otherwise would help with all of this. No need to retain author or anything (is few liner), just lift it/squash all right. -- 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] laeubi commented on pull request #706: [MNG-7432] Proposed UT for maven-3.9.x and 3.8.x
laeubi commented on PR #706: URL: https://github.com/apache/maven/pull/706#issuecomment-1087462382 All right I'll try that! Thanks for the Test it looks quite straight forward but I'm not sure I would have been able to come up with such one :-) -- 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-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516841#comment-17516841
]
Christopher Tubbs commented on SUREFIRE-2035:
-
I've created a very minimal example that demonstrates this bug:
https://github.com/ctubbsii/surefire-2035-example
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516853#comment-17516853
]
Slawomir Jaranowski commented on SUREFIRE-2035:
---
Please try: {{3.0.0-M6}} - released last weekend. :-)
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] laeubi commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on PR #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1087632670 @cstamas I have now fetched your test as well into this PR. -- 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-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516865#comment-17516865
]
Christopher Tubbs commented on SUREFIRE-2035:
-
Well then, M6 works fine, at least with my demo project.
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MRESOLVER-248) Make DF and BF collector implementations coexists
[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-248:
--
Fix Version/s: 1.8.0
> Make DF and BF collector implementations coexists
> -
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MRESOLVER-248) Make DF and BF collector implementations coexists
[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák reassigned MRESOLVER-248:
-
Assignee: Tamás Cservenák
> Make DF and BF collector implementations coexists
> -
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resolver] cstamas opened a new pull request, #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas opened a new pull request, #161: URL: https://github.com/apache/maven-resolver/pull/161 Revive replaced DF collector, and make them coexists. Default one is "old" DF, while new BF may be activated on demand (based on session config). --- https://issues.apache.org/jira/browse/MRESOLVER-248 -- 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] cstamas commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1087715982 @caiwei-ebay ping -- 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] cstamas commented on pull request #160: [MRESOLVER-248] DependencyCollector: let DF vs BF implementations coexists
cstamas commented on PR #160: URL: https://github.com/apache/maven-resolver/pull/160#issuecomment-1087744421 Superseded by https://github.com/apache/maven-resolver/pull/161 -- 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] cstamas closed pull request #160: [MRESOLVER-248] DependencyCollector: let DF vs BF implementations coexists
cstamas closed pull request #160: [MRESOLVER-248] DependencyCollector: let DF vs BF implementations coexists URL: https://github.com/apache/maven-resolver/pull/160 -- 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] slawekjaranowski commented on pull request #505: [SUREFIRE-2055] Always show random seed
slawekjaranowski commented on PR #505: URL: https://github.com/apache/maven-surefire/pull/505#issuecomment-1087751837 There is IT test: [RunOrderIT](https://github.com/apache/maven-surefire/blob/master/surefire-its/src/test/java/org/apache/maven/surefire/its/RunOrderIT.java) Maybe assertions can be added to verify it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516939#comment-17516939
]
Slawomir Jaranowski commented on SUREFIRE-2035:
---
So please try with your production code.
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516946#comment-17516946
]
Christopher Tubbs commented on SUREFIRE-2035:
-
I'm still re-running some of our project tests to be sure there aren't any
other problems with M6 (so far, there doesn't seem to be). I can verify that
the few tests that were failing in our project with M5 now also pass with M6.
So, I think this ticket can be closed.
If anybody knows which patch in M6 fixed this, please link it to the JIRA or
mention its git commit here. If there's a regression in future and somebody
finds this issue, that link might help a future developer identify the
underlying code that should be fixed.
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated SUREFIRE-2035:
Attachment: surefire-2035-example-main.zip
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
> Attachments: surefire-2035-example-main.zip
>
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516960#comment-17516960
]
Christopher Tubbs commented on SUREFIRE-2035:
-
All project tests pass with M6. I've attached the demo project to this issue,
so I can delete the no-longer needed GitHub repo.
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
> Attachments: surefire-2035-example-main.zip
>
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MCLEAN-99) Generated wrong PMD Page
Karl Heinz Marbaise created MCLEAN-99: - Summary: Generated wrong PMD Page Key: MCLEAN-99 URL: https://issues.apache.org/jira/browse/MCLEAN-99 Project: Maven Clean Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Karl Heinz Marbaise Fix For: 3.3.0 The generated page contains a bug in pmd report. Upgrade to Maven PMD Plugin Version 3.16.0 will fix the issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MCLEAN-100) Generated TagList Report is empty
Karl Heinz Marbaise created MCLEAN-100: -- Summary: Generated TagList Report is empty Key: MCLEAN-100 URL: https://issues.apache.org/jira/browse/MCLEAN-100 Project: Maven Clean Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Karl Heinz Marbaise Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MCLEAN-101) Wrong Jenkins URL
Karl Heinz Marbaise created MCLEAN-101: -- Summary: Wrong Jenkins URL Key: MCLEAN-101 URL: https://issues.apache.org/jira/browse/MCLEAN-101 Project: Maven Clean Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Karl Heinz Marbaise Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #144: Fix [MNG-828]
slawekjaranowski merged PR #144: URL: https://github.com/apache/maven-integration-testing/pull/144 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] slawekjaranowski commented on pull request #144: Fix [MNG-828]
slawekjaranowski commented on PR #144: URL: https://github.com/apache/maven-integration-testing/pull/144#issuecomment-1087860514 thx -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MEAR-308) Facing issues with "deleting outdated resource"
Rich M created MEAR-308: --- Summary: Facing issues with "deleting outdated resource" Key: MEAR-308 URL: https://issues.apache.org/jira/browse/MEAR-308 Project: Maven EAR Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Rich M Attachments: build.log, earmetainfissue.zip I am using maven-resources plugin to copy an additional file insider EAR META-INF folder. It works fine for the first time with clean. But when run again without clean, EAR plugin deletes the file saying "deleting outdated resource...". The pipeline runs the clean install first, and then run mvn deploy at later stage. Since mvn deploy builds ear again, it results in ear without the additional file. Here is a sample code attached. To recreate the problem: # Run mvn clean package. Note that \target\testear-1.0\META-INF will have 2 files. # Run mvn package. \target\testear-1.0\META-INF will have only 1 file now. How can this behavior be fixed ? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-828) log all mojo parameters and their populated values in debug mode
[ https://issues.apache.org/jira/browse/MNG-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517037#comment-17517037 ] Hudson commented on MNG-828: Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-705 #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-705/2/ > log all mojo parameters and their populated values in debug mode > > > Key: MNG-828 > URL: https://issues.apache.org/jira/browse/MNG-828 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0 (RC) > > > when we have this, we should remove the debugging code from plugins such as > ear that do this manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1087902959 I think I collapsed/deduped mostly what was obvious... -- 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-828) log all mojo parameters and their populated values in debug mode
[ https://issues.apache.org/jira/browse/MNG-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517050#comment-17517050 ] Hudson commented on MNG-828: Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-702 #3 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-702/3/ > log all mojo parameters and their populated values in debug mode > > > Key: MNG-828 > URL: https://issues.apache.org/jira/browse/MNG-828 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0 (RC) > > > when we have this, we should remove the debugging code from plugins such as > ear that do this manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
michael-o commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842058117
##
maven-resolver-impl/src/main/java/org/eclipse/aether/impl/guice/AetherModule.java:
##
@@ -212,6 +221,19 @@ protected void configure()
}
+@Provides
+@Singleton
+Map dependencyCollectorDelegates(
+@Named( BfDependencyCollector.NAME ) DependencyCollectorDelegate
bf,
+@Named( DfDependencyCollector.NAME ) DependencyCollectorDelegate df
+)
+{
+Map providedChecksumsSource = new
HashMap<>();
Review Comment:
`providedChecksumsSource` copy and paste?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/CachingArtifactTypeRegistry.java:
##
@@ -29,7 +29,7 @@
/**
* A short-lived artifact type registry that caches results from a presumedly
slower type registry.
*/
-class CachingArtifactTypeRegistry
+public class CachingArtifactTypeRegistry
Review Comment:
If this is logically internal, you should document it as such.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollectionContext.java:
##
@@ -29,7 +29,7 @@
/**
* @see DefaultDependencyCollector
*/
-final class DefaultDependencyCollectionContext
+public final class DefaultDependencyCollectionContext
Review Comment:
If this is logically internal, you should document it as such.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DataPool.java:
##
@@ -49,7 +49,7 @@
/**
*/
-final class DataPool
+public final class DataPool
Review Comment:
If this is logically internal, you should document it as such.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCycle.java:
##
@@ -30,17 +30,16 @@
import org.eclipse.aether.util.artifact.ArtifactIdUtils;
/**
- * @see DefaultDependencyCollector
+ * Default implementation of {@link DependencyCycle}.
*/
-final class DefaultDependencyCycle
+public final class DefaultDependencyCycle
Review Comment:
If this is logically internal, you should document it as such.
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfProcessingContext.java:
##
@@ -29,7 +29,7 @@
import org.eclipse.aether.graph.DependencyNode;
import org.eclipse.aether.repository.RemoteRepository;
-final class DependencyProcessingContext
+final class BfProcessingContext
Review Comment:
`BfDependencyProcessingContext`?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegate.java:
##
@@ -0,0 +1,96 @@
+package org.eclipse.aether.internal.impl.collect;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.impl.ArtifactDescriptorReader;
+import org.eclipse.aether.impl.DependencyCollector;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+import org.eclipse.aether.impl.VersionRangeResolver;
+import org.eclipse.aether.spi.locator.ServiceLocator;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * The delegate to the actual implementation.
+ *
+ * @since 1.8.0
+ */
+public abstract class DependencyCollectorDelegate implements
DependencyCollector
+{
+protected static final String CONFIG_PROP_MAX_EXCEPTIONS =
"aether.dependencyCollector.maxExceptions";
+
+protected static final int CONFIG_PROP_MAX_EXCEPTIONS_DEFAULT = 50;
+
+protected static final String CONFIG_PROP_MAX_CYCLES =
"aether.dependencyCollector.maxCycles";
+
+protected static final int CONFIG_PROP_MAX_CYCLES_DEFAULT = 10;
+
+protected final Logger logger = LoggerFactory.getLogger( getClass() );
+
+protected RemoteRepositoryManager remoteRepositoryManager;
+
+protected ArtifactDescriptorReader descriptorReader;
+
+protected VersionRangeResolver versionRangeResolver;
+
+public DependencyCollectorDelegate()
+{
+// enables default constructor
+}
+
+protected DependencyCollectorDelegate( RemoteRepositoryManager
remoteRepositoryManager,
[jira] [Assigned] (SUREFIRE-2044) Upgrade Maven Verifier to 1.8.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned SUREFIRE-2044: - Assignee: Slawomir Jaranowski > Upgrade Maven Verifier to 1.8.0 > --- > > Key: SUREFIRE-2044 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2044 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > > - check deprecated method in Verifier -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski opened a new pull request, #507: [SUREFIRE-2044] Upgrade Maven Verifier to 1.8.0
slawekjaranowski opened a new pull request, #507: URL: https://github.com/apache/maven-surefire/pull/507 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2056) BufferOverflowException when encoding message with null testId
[
https://issues.apache.org/jira/browse/SUREFIRE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517125#comment-17517125
]
Falko Modler commented on SUREFIRE-2056:
I seem to be hitting the same problem in Quarkus CI (e.g. in
{{io.quarkus.devtools.codestarts.quarkus.HibernateOrmCodestartTest}} or
{{io.quarkus.devtools.codestarts.quarkus.RESTEasyReactiveCodestartsTest}}).
> BufferOverflowException when encoding message with null testId
> --
>
> Key: SUREFIRE-2056
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Yoann Rodière
>Priority: Major
>
> The problem seems to have been introduced here:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
> {code}
> int bufferMaxLength = estimateBufferLength(
> eventType.getOpcode().length(), runMode, encoder, 0,
> testRunId == null ? 0 : 1, message );
> {code}
> The buffer estimate seems to ignore the testRunId field completely when the
> testRunId is null, but the {{encodeHeader}} method still adds content to the
> buffer even when the testRunId is null, resulting in a buffer overflow:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
> {code}
> result.put( (byte) ( testRunId == null ? 0 : 1 ) );
> if ( testRunId != null )
> {
> result.putLong( testRunId );
> }
> result.put( (byte) ':' );
> {code}
> Sending a PR shortly.
> Stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
> at
> org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at
> org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
> at
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$
[GitHub] [maven-mvnd] aalmiray commented on pull request #574: Refactor build and release workflows
aalmiray commented on PR #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1088026094 @ppalaga @gnodet I've refreshed this PR with latest changes from `master`. Do you have some time to review the proposed changes? -- 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 a diff in pull request #507: [SUREFIRE-2044] Upgrade Maven Verifier to 1.8.0
Tibor17 commented on code in PR #507:
URL: https://github.com/apache/maven-surefire/pull/507#discussion_r842182337
##
surefire-its/src/test/java/org/apache/maven/surefire/its/fixture/MavenLauncher.java:
##
@@ -186,9 +186,9 @@ public MavenLauncher addEnvVar( String key, String value )
return this;
}
-public MavenLauncher assertNotPresent( String subFile )
+public MavenLauncher verifyFileNotPresent( String subFile ) throws
VerificationException
{
-getVerifier().assertFileNotPresent( getValidator().getSubFile( subFile
).getAbsolutePath() );
Review Comment:
Was this method renamed in new verifier?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (SUREFIRE-2056) BufferOverflowException when encoding message with null testId
[
https://issues.apache.org/jira/browse/SUREFIRE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2056:
---
Fix Version/s: 3.0.0-M7
> BufferOverflowException when encoding message with null testId
> --
>
> Key: SUREFIRE-2056
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2056
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Yoann Rodière
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The problem seems to have been introduced here:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-a901d2e995f3d9e7ca75988975cefff9bb5f88686c3d0c8fc8696bc749253e8cR396
> {code}
> int bufferMaxLength = estimateBufferLength(
> eventType.getOpcode().length(), runMode, encoder, 0,
> testRunId == null ? 0 : 1, message );
> {code}
> The buffer estimate seems to ignore the testRunId field completely when the
> testRunId is null, but the {{encodeHeader}} method still adds content to the
> buffer even when the testRunId is null, resulting in a buffer overflow:
> https://github.com/apache/maven-surefire/commit/79db90338fb474f91c76991388a35bc412ee1d46#diff-2c1d8cdb8be334b20d2b1befed41ac6776b024a3a8ae040e2413569ead512a21R92-R97
> {code}
> result.put( (byte) ( testRunId == null ? 0 : 1 ) );
> if ( testRunId != null )
> {
> result.putLong( testRunId );
> }
> result.put( (byte) ':' );
> {code}
> Sending a PR shortly.
> Stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
> at
> org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
> at
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at
> org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
> at
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> at
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.
[jira] [Created] (SUREFIRE-2057) JPMS Regression: requires static module not include anymore
Olivier Lamy created SUREFIRE-2057: -- Summary: JPMS Regression: requires static module not include anymore Key: SUREFIRE-2057 URL: https://issues.apache.org/jira/browse/SUREFIRE-2057 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.0.0-M7 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] olamy opened a new pull request, #508: [SUREFIRE-2057] jpms requires static must be included
olamy opened a new pull request, #508: URL: https://github.com/apache/maven-surefire/pull/508 Signed-off-by: Olivier Lamy Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #506: SUREFIRE-2056 BufferOverflowException when encoding message with null testId
Tibor17 commented on PR #506: URL: https://github.com/apache/maven-surefire/pull/506#issuecomment-1088109075 @yrodiere It would not be a problem to modify the [existing test](https://github.com/apache/maven-surefire/blob/4e0a769227fa185ffbfdf6bf68b67294868b8851/surefire-booter/src/test/java/org/apache/maven/surefire/booter/spi/EventChannelEncoderTest.java#L1194). We have too many tests in this class. Some are similar and eligible for ParameterizedTests. Adding more would complicate the refactoring. Thus it is better to modify the existing one for testRunId. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MJAVADOC-709) JDK 17 support
Gili created MJAVADOC-709:
-
Summary: JDK 17 support
Key: MJAVADOC-709
URL: https://issues.apache.org/jira/browse/MJAVADOC-709
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.3.2
Reporter: Gili
The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal I
get the following error:
{code:java}
Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
major.minor version 61.0
at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
(ModuleInfo.java:1091)
at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
(BinaryModuleInfoParser.java:37)
at
org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
(AbstractBinaryModuleInfoParser.java:90)
at
org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
(AbstractBinaryModuleInfoParser.java:38)
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
(LocationManager.java:364)
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
(LocationManager.java:135)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
(AbstractJavadocMojo.java:5232)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
(AbstractJavadocMojo.java:2213)
at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
(JavadocJar.java:189)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
(AbstractJavadocMojo.java:2041)
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 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)
at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-709) JDK 17 support
[
https://issues.apache.org/jira/browse/MJAVADOC-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517164#comment-17517164
]
Gili commented on MJAVADOC-709:
---
Related to https://github.com/codehaus-plexus/plexus-languages/issues/120
> JDK 17 support
> --
>
> Key: MJAVADOC-709
> URL: https://issues.apache.org/jira/browse/MJAVADOC-709
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.2
>Reporter: Gili
>Priority: Blocker
>
> The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal
> I get the following error:
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
> major.minor version 61.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
> (BinaryModuleInfoParser.java:37)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:90)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:38)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:364)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:135)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
> (AbstractJavadocMojo.java:5232)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2213)
> at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
> (JavadocJar.java:189)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:2041)
> 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 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)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
> Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resources-plugin] dependabot[bot] opened a new pull request, #18: Bump commons-io from 1.4 to 2.7 in /src/it/user-filters
dependabot[bot] opened a new pull request, #18: URL: https://github.com/apache/maven-resources-plugin/pull/18 Bumps commons-io from 1.4 to 2.7. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-resources-plugin/network/alerts). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] dependabot[bot] closed pull request #189: Bump version.spring from 5.3.15 to 5.3.17
dependabot[bot] closed pull request #189: Bump version.spring from 5.3.15 to 5.3.17 URL: https://github.com/apache/maven-indexer/pull/189 -- 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-indexer] dependabot[bot] opened a new pull request, #191: Bump version.spring from 5.3.15 to 5.3.18
dependabot[bot] opened a new pull request, #191: URL: https://github.com/apache/maven-indexer/pull/191 Bumps `version.spring` from 5.3.15 to 5.3.18. Updates `spring-beans` from 5.3.15 to 5.3.18 Release notes Sourced from https://github.com/spring-projects/spring-framework/releases";>spring-beans's releases. v5.3.18 :star: New Features Restrict access to property paths on Class references https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28261";>#28261 Introduce cancel(boolean mayInterruptIfRunning) in ScheduledTask https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28233";>#28233 :lady_beetle: Bug Fixes Move off deprecated API in SessionTransactionData https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28234";>#28234 :notebook_with_decorative_cover: Documentation Introduce warnings in documentation of SerializationUtils https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28246";>#28246 Update copyright date in reference manual https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28237";>#28237 @Transactional test does not execute all JPA lifecycle callback methods https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28228";>#28228 :heart: Contributors We'd like to thank all the contributors who worked on this release! https://github.com/izeye";>@izeye https://github.com/quaff";>@quaff v5.3.17 :star: New Features Using DataClassRowMapper causes "No property found for column" debug messages in logs https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28179";>#28179 Improve diagnostics in SpEL for large array creation https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28145";>#28145 Support custom HTTP status in client-side REST testing support https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/28105";>#28105 AsyncRestTemplate logging too verbose https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28049";>#28049 :lady_beetle: Bug Fixes java.lang.NoClassDefFoundError: org/springframework/cglib/beans/BeanMapEmitter https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28110";>#28110 CronExpression fails to calculate properly next execution when running on the day of winter daylight saving time https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28095";>#28095 Private init/destroy method may be invoked twice https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28083";>#28083 MappingJacksonValue and Jackson2CodecSupport#registerObjectMappersForType do not work together https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28045";>#28045 SpEL fails to recover from error during MIXED mode compilation https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28043";>#28043 When returning a ResponseEntity with a Flux while the function is suspended, it fails to encode the body https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27809";>#27809 :notebook_with_decorative_cover: Documentation Improve documentation for @EnabledIf and @DisabledIf test support https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28157";>#28157 Links to Spring Security are broken in the reference guide https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28135";>#28135 Document that transaction rollback rules may result in unintentional matches https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/28125";>#28125 Improve documentation for TestContext events https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27757";>#27757 Clarify behavior for generics support in BeanUtils.copyProperties https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27259";>#27259 :hammer: Dependency Upgrades ... (truncated) Commits https://github.com/spring-projects/spring-framework/commit/707a24c48b21fc35e8be715afc80f020a24a9714";>707a24c Release v5.3.18 https://github.com/spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15";>002546b Refine PropertyDescriptor filtering https://github.com/spring-projects/spring-framework/commit/1627f57f1f77abe17dd607c75476b9e4cb22ffbb";>1627f57 Disable flaky integration tests for now https://github.com/spring-projects/spring-framework/commit/3811cd4c0a0be3aac6e842cf1890610ce986449d";>3811cd4 Introduce warnings in documentation of SerializationUtils https://github.com/spring-projects/spring-framework/commit/d927e3736483c8f1e0c012fa1
[GitHub] [maven-indexer] dependabot[bot] commented on pull request #189: Bump version.spring from 5.3.15 to 5.3.17
dependabot[bot] commented on PR #189: URL: https://github.com/apache/maven-indexer/pull/189#issuecomment-1088261087 Superseded by #191. -- 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-jdeps-plugin] dependabot[bot] opened a new pull request, #5: Bump junit from 4.11 to 4.13.1
dependabot[bot] opened a new pull request, #5: URL: https://github.com/apache/maven-jdeps-plugin/pull/5 Bumps [junit](https://github.com/junit-team/junit4) from 4.11 to 4.13.1. Release notes Sourced from https://github.com/junit-team/junit4/releases";>junit's releases. JUnit 4.13.1 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md";>release notes for details. JUnit 4.13 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md";>release notes for details. JUnit 4.13 RC 2 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes for details. JUnit 4.13 RC 1 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes for details. JUnit 4.13 Beta 3 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes for details. JUnit 4.13 Beta 2 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes for details. JUnit 4.13 Beta 1 Please refer to the https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes for details. JUnit 4.12 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md";>release notes for details. JUnit 4.12 Beta 3 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md";>release notes for details. JUnit 4.12 Beta 2 No release notes provided. JUnit 4.12 Beta 1 No release notes provided. Commits https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66";>1b683f4 [maven-release-plugin] prepare release r4.13.1 https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2";>ce6ce3a Draft 4.13.1 release notes https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24";>c29dd82 Change version to 4.13.1-SNAPSHOT https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567";>1d17486 Add a link to assertThrows in exception testing https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9";>543905d Use separate line for annotation in Javadoc https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944";>510e906 Add sub headlines to class Javadoc https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae";>610155b Merge pull request from GHSA-269g-pwp5-87pp https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec";>b6cfd1e Explicitly wrap float parameter for consistency (https://github-redirect.dependabot.com/junit-team/junit4/issues/1671";>#1671) https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646";>a5d205c Fix GitHub link in FAQ (https://github-redirect.dependabot.com/junit-team/junit4/issues/1672";>#1672) https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8";>3a5c6b4 Deprecated since jdk9 replacing constructor instance of Double and Float (https://github-redirect.dependabot.com/junit-team/junit4/issues/1660";>#1660) Additional commits viewable in https://github.com/junit-team/junit4/compare/r4.11...r4.13.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
[GitHub] [maven-doap-plugin] dependabot[bot] opened a new pull request, #1: Bump jena-core from 2.11.2 to 4.2.0
dependabot[bot] opened a new pull request, #1: URL: https://github.com/apache/maven-doap-plugin/pull/1 Bumps jena-core from 2.11.2 to 4.2.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) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-doap-plugin/network/alerts). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-plugin-testing] dependabot[bot] opened a new pull request, #20: Bump commons-io from 2.6 to 2.7 in /maven-plugin-testing-harness
dependabot[bot] opened a new pull request, #20: URL: https://github.com/apache/maven-plugin-testing/pull/20 Bumps commons-io from 2.6 to 2.7. [](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) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-plugin-testing/network/alerts). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] gzm55 opened a new pull request, #128: [MSHADE-124] keep original basedir after set d-r-p location to build dir
gzm55 opened a new pull request, #128:
URL: https://github.com/apache/maven-shade-plugin/pull/128
From maven 3.2.5, the pom and basedir are seperated
(https://github.com/apache/maven/commit/c15226f13f6d071d1e926880139d350cc4546b6f),
and add new api `MavenProject::setPomFile()` to only upodate pom location.
In this pr, the minimal maven version is bumped to 3.2.5, then use
`setPomFile` to only update pom file location, leaving `${basedir}`
unchanged.
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MSHADE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MSHADE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MSHADE-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.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [ ] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
--
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] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517234#comment-17517234 ] James Z.M. Gao commented on MSHADE-124: --- as comment in MSHAD-160 said, we can leave the basedir unchanged using maven 3.2.5 api `MavenProject::setPomFile`, plz review the pr https://github.com/apache/maven-shade-plugin/pull/128 > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-160) change default location of dependency-reduced-pom.xml
[
https://issues.apache.org/jira/browse/MSHADE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517235#comment-17517235
]
James Z.M. Gao commented on MSHADE-160:
---
as [~rfscholte] suggest, a new
[pr|https://github.com/apache/maven-shade-plugin/pull/128] can solve
MSHADE-124, then this issue can be solved finally
> change default location of dependency-reduced-pom.xml
> -
>
> Key: MSHADE-160
> URL: https://issues.apache.org/jira/browse/MSHADE-160
> Project: Maven Shade Plugin
> Issue Type: Wish
>Affects Versions: 2.2
>Reporter: Gabriele Catania
>Priority: Trivial
> Fix For: more-investigation
>
>
> The current defaults of the plugin place the dependency reduced pom alongside
> the pom.xml as a sibling file.
> Given that it's a generated file, wouldn't it be best to place it by default
> inside the target directory?
> either something like this:
> {code:xml}
>
> ${project.build.directory}/dependency-reduced-pom.xml
> {code}
> or, even better (to conform with conventions from other plugins):
> {code:xml}
>
> ${project.build.directory}/generated/shade/dependency-reduced-pom.xml
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on PR #161: URL: https://github.com/apache/maven-resolver/pull/161#issuecomment-1088318575 General remark: the convention to name package as "internal" or "impl" should automatically imply this is INTERNAL thing (AFAIK, some OSGi tooling and Takari life-cycle even enforce this). In this case we deal with "internal.impl" :smile: so IMHO it should be really really clear to developer that this is internal implementation... Am just saying this is something generally used, but agree, will update javadoc -- 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] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842415466
##
maven-resolver-impl/src/main/java/org/eclipse/aether/impl/guice/AetherModule.java:
##
@@ -212,6 +221,19 @@ protected void configure()
}
+@Provides
+@Singleton
+Map dependencyCollectorDelegates(
+@Named( BfDependencyCollector.NAME ) DependencyCollectorDelegate
bf,
+@Named( DfDependencyCollector.NAME ) DependencyCollectorDelegate df
+)
+{
+Map providedChecksumsSource = new
HashMap<>();
Review Comment:
fixed
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/CachingArtifactTypeRegistry.java:
##
@@ -29,7 +29,7 @@
/**
* A short-lived artifact type registry that caches results from a presumedly
slower type registry.
*/
-class CachingArtifactTypeRegistry
+public class CachingArtifactTypeRegistry
Review Comment:
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] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161: URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842415618 ## maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DataPool.java: ## @@ -49,7 +49,7 @@ /** */ -final class DataPool +public final class DataPool Review Comment: fixed ## maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollectionContext.java: ## @@ -29,7 +29,7 @@ /** * @see DefaultDependencyCollector */ -final class DefaultDependencyCollectionContext +public final class DefaultDependencyCollectionContext Review Comment: 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] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842415793
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCycle.java:
##
@@ -30,17 +30,16 @@
import org.eclipse.aether.util.artifact.ArtifactIdUtils;
/**
- * @see DefaultDependencyCollector
+ * Default implementation of {@link DependencyCycle}.
*/
-final class DefaultDependencyCycle
+public final class DefaultDependencyCycle
Review Comment:
fixed
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultVersionFilterContext.java:
##
@@ -36,7 +36,7 @@
/**
* @see DefaultDependencyCollector
*/
-final class DefaultVersionFilterContext
+public final class DefaultVersionFilterContext
Review Comment:
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-surefire] yrodiere commented on pull request #506: SUREFIRE-2056 BufferOverflowException when encoding message with null testId
yrodiere commented on PR #506: URL: https://github.com/apache/maven-surefire/pull/506#issuecomment-1088329572 @Tibor17 I would have, but the bug only occurs the message is an empty string, unlike the existing test, and I assumed this would be too big of a change? Not testing the nominal case with both a message and a test run ID seemed unwise, but what do I know :) I suspect the reason we don't get the bug with a non-empty message is that we over-allocate space in the buffer for the message: length * : https://github.com/apache/maven-surefire/blob/79db90338fb474f91c76991388a35bc412ee1d46/surefire-api/src/main/java/org/apache/maven/surefire/api/stream/AbstractStreamEncoder.java#L206 In the case of UTF-8 the max bytes per char is `3.0f`, while most characters are just 1 byte, so this leaves a few extra bytes in the buffer that can be used for something else, and this over-allocation ends up "compensating" the bug. I adjusted the test name and added a comment to make this clear. Of course if you just wanted me to keep the testing code and shove it into the existing test method, I can do that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842415939
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegate.java:
##
@@ -0,0 +1,96 @@
+package org.eclipse.aether.internal.impl.collect;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.impl.ArtifactDescriptorReader;
+import org.eclipse.aether.impl.DependencyCollector;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+import org.eclipse.aether.impl.VersionRangeResolver;
+import org.eclipse.aether.spi.locator.ServiceLocator;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * The delegate to the actual implementation.
+ *
+ * @since 1.8.0
+ */
+public abstract class DependencyCollectorDelegate implements
DependencyCollector
+{
+protected static final String CONFIG_PROP_MAX_EXCEPTIONS =
"aether.dependencyCollector.maxExceptions";
+
+protected static final int CONFIG_PROP_MAX_EXCEPTIONS_DEFAULT = 50;
+
+protected static final String CONFIG_PROP_MAX_CYCLES =
"aether.dependencyCollector.maxCycles";
+
+protected static final int CONFIG_PROP_MAX_CYCLES_DEFAULT = 10;
+
+protected final Logger logger = LoggerFactory.getLogger( getClass() );
+
+protected RemoteRepositoryManager remoteRepositoryManager;
+
+protected ArtifactDescriptorReader descriptorReader;
+
+protected VersionRangeResolver versionRangeResolver;
+
+public DependencyCollectorDelegate()
+{
+// enables default constructor
+}
+
+protected DependencyCollectorDelegate( RemoteRepositoryManager
remoteRepositoryManager,
+ ArtifactDescriptorReader artifactDescriptorReader,
+ VersionRangeResolver versionRangeResolver )
+{
+setRemoteRepositoryManager( remoteRepositoryManager );
+setArtifactDescriptorReader( artifactDescriptorReader );
+setVersionRangeResolver( versionRangeResolver );
+}
+
+public void initService( ServiceLocator locator )
+{
+setRemoteRepositoryManager( locator.getService(
RemoteRepositoryManager.class ) );
+setArtifactDescriptorReader( locator.getService(
ArtifactDescriptorReader.class ) );
+setVersionRangeResolver( locator.getService(
VersionRangeResolver.class ) );
+}
+
+public DependencyCollector setRemoteRepositoryManager(
RemoteRepositoryManager remoteRepositoryManager )
+{
+this.remoteRepositoryManager =
+requireNonNull( remoteRepositoryManager, "remote repository
provider cannot be null" );
Review Comment:
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] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161: URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842416268 ## maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfProcessingContext.java: ## @@ -29,7 +29,7 @@ import org.eclipse.aether.graph.DependencyNode; import org.eclipse.aether.repository.RemoteRepository; -final class DependencyProcessingContext +final class BfProcessingContext Review Comment: Named it as DependencyProcessingContext as it is already BF specific (same naming pattern that Skipper has) -- 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] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161: URL: https://github.com/apache/maven-resolver/pull/161#discussion_r842419539 ## maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyGraphTransformationContext.java: ## @@ -28,15 +28,15 @@ /** */ -class DefaultDependencyGraphTransformationContext +public class DefaultDependencyGraphTransformationContext Review Comment: 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
