[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516208#comment-17516208
]
Alexander Kriegisch commented on SUREFIRE-2004:
---
[~tibordigana], I noticed the status change to "waiting for feedback", which
occurred a couple of hours *after* you got feedback and and the reproducer you
requested already. Maybe you did not notice, so I am reminding you. I think the
ball is in your court.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana edited comment on SUREFIRE-2033 at 4/2/22 12:10 AM:
-
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for. The documentation often describes POM configuration and
dependencies. I believe that the user would understand the principles and he
would better help himself.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
It is not worth to use {{junit-platform-runner}} if your tests are completely
written in JUnit5 and no JUnit4 tests. Then you should delete the
{{junit-platform-runner}} from the code, means some JUnit4 Suite class, and
from dependencies, and you would obtain nice full version of JUnit5 tests and
Surefire would automatically activate JUnit5 provider for you. This was my
meaning. So that the {{junit-platform-runner}} is useful for some intermediate
time but it should not be something long lasting in the project.
was (Author: tibor17):
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for. The documentation often describes POM configuration and
dependencies. I believe that the user would understand the principles and he
would better help himself.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO]
[jira] [Comment Edited] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana edited comment on SUREFIRE-2033 at 4/1/22 11:44 PM:
-
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for. The documentation often describes POM configuration and
dependencies. I believe that the user would understand the principles and he
would better help himself.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
was (Author: tibor17):
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD
[jira] [Comment Edited] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana edited comment on SUREFIRE-2033 at 4/1/22 11:33 PM:
-
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 tests to the junit5 tests which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
was (Author: tibor17):
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 test to the junit5 test which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516168#comment-17516168
]
Tibor Digana commented on SUREFIRE-2033:
[~roxspring]
The
[documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#JUnit_Runner]
describes the POM configuration for JUnit Runner. Does it mean that JUnit5
provider has to be activated? The user experiences is his JUnit5 tests and he
does not necessarily can see what is under the hood. His main focus is his
junit5/platform tests but the junit4 starter/suite is just a small tiny layer.
He can mix junit4 and half-migrated junit5 tests with this approach of course
but the user is moving his junit4 test to the junit5 test which is his target
what he is aiming for.
The {{junit-platform-runner}} is JUnit4 specific. It is JUnit4 runner, so the
{{surefire-junit4}} provider should be activated.
It means that the ProviderInfo.isApplicable() must return false for
JUnitPlatformProviderInfo, and so the JUnit4 provider should be activated. This
was the previous design of code and it still has the same meaning even after
your PR which is right IMHO.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test
[jira] [Comment Edited] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516164#comment-17516164
]
Tibor Digana edited comment on SUREFIRE-1879 at 4/1/22 11:19 PM:
-
ok, bad luck, we have to investigate it better. It would not be that easy, I
think.
was (Author: tibor17):
ok, bad luck, we have to investigate it better. It would not be easy, I think.
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516164#comment-17516164
]
Tibor Digana commented on SUREFIRE-1879:
ok, bad luck, we have to investigate it better. It would not be easy, I think.
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-integration-testing] slawekjaranowski commented on pull request #143: [MNG-5222] IT test - warn about deprecated plugin params
slawekjaranowski commented on pull request #143: URL: https://github.com/apache/maven-integration-testing/pull/143#issuecomment-1086387767 https://github.com/apache/maven/pull/705 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] slawekjaranowski commented on pull request #285: [MNG-5222] - Maven 3 no longer logs warnings about deprecated parameter in plugin
slawekjaranowski commented on pull request #285: URL: https://github.com/apache/maven/pull/285#issuecomment-1086386535 @belingueres Thanks for contributing - your commit and credential will be preserved in my PR, this one can be closed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] slawekjaranowski closed pull request #285: [MNG-5222] - Maven 3 no longer logs warnings about deprecated parameter in plugin
slawekjaranowski closed pull request #285: URL: https://github.com/apache/maven/pull/285 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] slawekjaranowski commented on pull request #285: [MNG-5222] - Maven 3 no longer logs warnings about deprecated parameter in plugin
slawekjaranowski commented on pull request #285: URL: https://github.com/apache/maven/pull/285#issuecomment-1086384399 Branch for change created with simple fix after IT tests - https://github.com/apache/maven/pull/705 and IT tests - https://github.com/apache/maven-integration-testing/pull/143 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] slawekjaranowski opened a new pull request #705: [MNG-5222] Maven 3 no longer logs warnings about deprecated plugin parameters
slawekjaranowski opened a new pull request #705: URL: https://github.com/apache/maven/pull/705 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516146#comment-17516146
]
Falko Modler edited comment on SUREFIRE-1879 at 4/1/22 9:50 PM:
[~tibordigana] I'm sorry, but M6 doesn't seem to fix this problem (tested with
the attached reproducer).
PS:
{quote}Falko, you often support Maven. The Maven is certainly the project you
like and you use Maven. You was never thinking about to join us in
development?{quote}
I'd be glad to help, I just don't have time for that at the moment.
was (Author: famod):
[~tibordigana] I'm sorry, but M6 doesn't seem to fix this problem (tested with
the attached reproducer).
PS:
{quote}
Falko, you often support Maven. The Maven is certainly the project you like and
you use Maven. You was never thinking about to join us in development?
{quote}
I'd be glad to help, I just don't have time for that at the moment.
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516146#comment-17516146
]
Falko Modler edited comment on SUREFIRE-1879 at 4/1/22 9:49 PM:
[~tibordigana] I'm sorry, but M6 doesn't seem to fix this problem (tested with
the attached reproducer).
PS:
{quote}
Falko, you often support Maven. The Maven is certainly the project you like and
you use Maven. You was never thinking about to join us in development?
{quote}
I'd be glad to help, I just don't have time for that at the moment.
was (Author: famod):
[~tibordigana] I'm sorry, but M6 doesn't seem to fix this problem (tested with
the attached reproducer).
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516146#comment-17516146
]
Falko Modler commented on SUREFIRE-1879:
[~tibordigana] I'm sorry, but M6 doesn't seem to fix this problem (tested with
the attached reproducer).
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-clean-plugin] dependabot[bot] closed pull request #15: Bump maven-plugins from 34 to 35
dependabot[bot] closed pull request #15: URL: https://github.com/apache/maven-clean-plugin/pull/15 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-clean-plugin] dependabot[bot] commented on pull request #15: Bump maven-plugins from 34 to 35
dependabot[bot] commented on pull request #15: URL: https://github.com/apache/maven-clean-plugin/pull/15#issuecomment-1086334913 Looks like org.apache.maven.plugins:maven-plugins is up-to-date now, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6564) Lack of ability to overwrite properties of specified dependencies
[
https://issues.apache.org/jira/browse/MNG-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516136#comment-17516136
]
Ralph Goers commented on MNG-6564:
--
I just want to add a practical side to this. We have a company-wide parent pom
that does
{code:java}
2.5.12
2020.0.5
3.1.7
{code}
Every project then has
{code:java}
org.springframework.cloud
spring-cloud-dependencies
${spring-cloud-dependencies.version}
pom
import
{code}
We are trying to add the spring-cloud-function version to remediate against one
of the latest Spring CVEs but the import uses version 3.1.6 instead of 3.1.7
since 3.1.6 is what spring-cloud-dependencies declares. So now, in addition to
just updating the parent pom version they have to also add
{code:java}
org.springframework.cloud
spring-cloud-function-dependencies
${spring-cloud-function.version}
pom
import
{code}
which, of course, is identical to what is inside of spring-cloud-dependencies.
Also, it must appear before the spring-cloud-dependencies declaration or else
it is ignored.
> Lack of ability to overwrite properties of specified dependencies
> -
>
> Key: MNG-6564
> URL: https://issues.apache.org/jira/browse/MNG-6564
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Rik Schaaf
>Priority: Major
>
> For example, if I want to update the flyway version to 4.2.0 in spring boot
> 1.5 (by default Flyway 3.2.1) I want to do something like this:
> {code:xml}
>
> 4.2.0
> 1.5.17.RELEASE
>
>
>
>
> org.springframework.boot
> spring-boot-dependencies
> ${springboot.version}
> pom
> import
>
>
>
> {code}
> The flyway dependency is already defined in the dependency management of
> spring-boot-dependencies:
> {code:xml}
>
> org.flywaydb
> flyway-core
> ${flyway.version}
>
> {code}
> But that same pom also defines flyway.version to be 3.2.1. When I include the
> flyway dependency in my own dependency management, my application does
> correctly use Flyway 4.2.0, but if I only provide the property, it
> incorrectly uses version 3.2.1, meaning that my property was ignored. I have
> heard from others that you can forcefully override a property by using a
> commandline parameter or an environment variable, but I would prefer to use a
> property in my pom file instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCLEAN-98) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MCLEAN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516128#comment-17516128 ] Hudson commented on MCLEAN-98: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-clean-plugin » master #5 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-clean-plugin/job/master/5/ > Upgrade maven-plugin parent to 35 > - > > Key: MCLEAN-98 > URL: https://issues.apache.org/jira/browse/MCLEAN-98 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > > Based on the upgrade to the newer parent the following upgrade had to be done: > * Upgrade Maven Plugin tools to 3.6.4 > * Changed maven-plugin-api scope to provided > * Upgrade maven-plugin-testing-harness to 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCLEAN-98) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MCLEAN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516125#comment-17516125 ] Karl Heinz Marbaise commented on MCLEAN-98: --- Done in [81b7e248d2c3a529498884346272cd7105305f3e|https://gitbox.apache.org/repos/asf?p=maven-clean-plugin.git;a=commitdiff;h=81b7e248d2c3a529498884346272cd7105305f3e] > Upgrade maven-plugin parent to 35 > - > > Key: MCLEAN-98 > URL: https://issues.apache.org/jira/browse/MCLEAN-98 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > > Based on the upgrade to the newer parent the following upgrade had to be done: > * Upgrade Maven Plugin tools to 3.6.4 > * Changed maven-plugin-api scope to provided > * Upgrade maven-plugin-testing-harness to 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MCLEAN-98) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MCLEAN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MCLEAN-98. - Resolution: Done > Upgrade maven-plugin parent to 35 > - > > Key: MCLEAN-98 > URL: https://issues.apache.org/jira/browse/MCLEAN-98 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > > Based on the upgrade to the newer parent the following upgrade had to be done: > * Upgrade Maven Plugin tools to 3.6.4 > * Changed maven-plugin-api scope to provided > * Upgrade maven-plugin-testing-harness to 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-clean-plugin] dependabot[bot] closed pull request #14: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.2
dependabot[bot] closed pull request #14: URL: https://github.com/apache/maven-clean-plugin/pull/14 -- 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-clean-plugin] dependabot[bot] commented on pull request #14: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.2
dependabot[bot] commented on pull request #14: URL: https://github.com/apache/maven-clean-plugin/pull/14#issuecomment-1086318761 Looks like org.apache.maven.plugins:maven-project-info-reports-plugin is no longer a dependency, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-clean-plugin] dependabot[bot] commented on pull request #12: Bump maven-javadoc-plugin from 3.3.1 to 3.3.2
dependabot[bot] commented on pull request #12: URL: https://github.com/apache/maven-clean-plugin/pull/12#issuecomment-1086318651 Looks like org.apache.maven.plugins:maven-javadoc-plugin is no longer a dependency, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-clean-plugin] dependabot[bot] closed pull request #12: Bump maven-javadoc-plugin from 3.3.1 to 3.3.2
dependabot[bot] closed pull request #12: URL: https://github.com/apache/maven-clean-plugin/pull/12 -- 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-clean-plugin] dependabot[bot] closed pull request #13: Bump maven-site-plugin from 3.10.0 to 3.11.0
dependabot[bot] closed pull request #13: URL: https://github.com/apache/maven-clean-plugin/pull/13 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-clean-plugin] dependabot[bot] commented on pull request #13: Bump maven-site-plugin from 3.10.0 to 3.11.0
dependabot[bot] commented on pull request #13: URL: https://github.com/apache/maven-clean-plugin/pull/13#issuecomment-1086318638 Looks like org.apache.maven.plugins:maven-site-plugin is no longer a dependency, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516124#comment-17516124 ] Hudson commented on MNG-7445: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #23 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/23/ > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCLEAN-97) Require Java 8
[ https://issues.apache.org/jira/browse/MCLEAN-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516123#comment-17516123 ] Karl Heinz Marbaise commented on MCLEAN-97: --- Had been done in de77b58 > Require Java 8 > -- > > Key: MCLEAN-97 > URL: https://issues.apache.org/jira/browse/MCLEAN-97 > Project: Maven Clean Plugin > Issue Type: Task >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MCLEAN-98) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MCLEAN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MCLEAN-98: -- Description: Based on the upgrade to the newer parent the following upgrade had to be done: * Upgrade Maven Plugin tools to 3.6.4 * Changed maven-plugin-api scope to provided * Upgrade maven-plugin-testing-harness to 3.3.0 was: Based on the upgrade to the newer parent the following upgrade had to be done: * Upgrade Maven Version to 3.2.5 (minimum Maven requirement) * Upgrade Maven Plugin tools to 3.6.4 * Changed maven-plugin-api scope to provided * Upgrade maven-plugin-testing-harness to 3.3.0 > Upgrade maven-plugin parent to 35 > - > > Key: MCLEAN-98 > URL: https://issues.apache.org/jira/browse/MCLEAN-98 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > > Based on the upgrade to the newer parent the following upgrade had to be done: > * Upgrade Maven Plugin tools to 3.6.4 > * Changed maven-plugin-api scope to provided > * Upgrade maven-plugin-testing-harness to 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MCLEAN-97) Require Java 8
[ https://issues.apache.org/jira/browse/MCLEAN-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MCLEAN-97. - Fix Version/s: 3.2.0 (was: 3.3.0) Resolution: Fixed > Require Java 8 > -- > > Key: MCLEAN-97 > URL: https://issues.apache.org/jira/browse/MCLEAN-97 > Project: Maven Clean Plugin > Issue Type: Task >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516120#comment-17516120 ] Hudson commented on MNG-7445: - Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/11/ > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- 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=17516121#comment-17516121 ] Hudson commented on MNG-828: Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/11/ > 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)
[jira] [Commented] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516115#comment-17516115 ] Hudson commented on MNG-7445: - Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #9 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/9/ > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MCLEAN-98) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MCLEAN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MCLEAN-98: -- Description: Based on the upgrade to the newer parent the following upgrade had to be done: * Upgrade Maven Version to 3.2.5 (minimum Maven requirement) * Upgrade Maven Plugin tools to 3.6.4 * Changed maven-plugin-api scope to provided * Upgrade maven-plugin-testing-harness to 3.3.0 > Upgrade maven-plugin parent to 35 > - > > Key: MCLEAN-98 > URL: https://issues.apache.org/jira/browse/MCLEAN-98 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > > Based on the upgrade to the newer parent the following upgrade had to be done: > * Upgrade Maven Version to 3.2.5 (minimum Maven requirement) > * Upgrade Maven Plugin tools to 3.6.4 > * Changed maven-plugin-api scope to provided > * Upgrade maven-plugin-testing-harness to 3.3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MCLEAN-98) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MCLEAN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MCLEAN-98: - Assignee: Karl Heinz Marbaise > Upgrade maven-plugin parent to 35 > - > > Key: MCLEAN-98 > URL: https://issues.apache.org/jira/browse/MCLEAN-98 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (MCLEAN-97) Require Java 8
[ https://issues.apache.org/jira/browse/MCLEAN-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reopened MCLEAN-97: --- > Require Java 8 > -- > > Key: MCLEAN-97 > URL: https://issues.apache.org/jira/browse/MCLEAN-97 > Project: Maven Clean Plugin > Issue Type: Task >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.3.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MCLEAN-97) Require Java 8
[ https://issues.apache.org/jira/browse/MCLEAN-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MCLEAN-97: -- Fix Version/s: 3.3.0 (was: 3.2.0) > Require Java 8 > -- > > Key: MCLEAN-97 > URL: https://issues.apache.org/jira/browse/MCLEAN-97 > Project: Maven Clean Plugin > Issue Type: Task >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.3.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] khmarbaise closed pull request #687: [MNG-7445] Refactoring, remove the useless line
khmarbaise closed pull request #687: URL: https://github.com/apache/maven/pull/687 -- 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] khmarbaise commented on pull request #687: [MNG-7445] Refactoring, remove the useless line
khmarbaise commented on pull request #687: URL: https://github.com/apache/maven/pull/687#issuecomment-1086293748 Thank you for your contribution. The change has been merged into * master - d92538b80f302fc40530468efe7ca7bf63b7ba52 * maven-3.8.x - 69bde0b901f983117032f674a3701d6a6eb4b716 * maven-3.9.x - f7b073f3eb88e4e82d5ec10a91d2bf6b442c03c6 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-7445. Resolution: Fixed > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MNG-7445: Assignee: Karl Heinz Marbaise > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-7445: - Fix Version/s: 3.8.x-candidate 3.9.0 4.0.0 > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MCLEAN-98) Upgrade maven-plugin parent to 35
Karl Heinz Marbaise created MCLEAN-98: - Summary: Upgrade maven-plugin parent to 35 Key: MCLEAN-98 URL: https://issues.apache.org/jira/browse/MCLEAN-98 Project: Maven Clean Plugin Issue Type: Improvement Affects Versions: 3.1.1 Reporter: Karl Heinz Marbaise Fix For: 3.1.1 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-scm] pzygielo commented on pull request #134: [SCM-976] GitExe Changelog supports current versions of git
pzygielo commented on pull request #134: URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1086282272 ping @michael-o -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7447) Several Improvements by using Stream API
[ https://issues.apache.org/jira/browse/MNG-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-7447: - Fix Version/s: 3.9.0 > Several Improvements by using Stream API > > > Key: MNG-7447 > URL: https://issues.apache.org/jira/browse/MNG-7447 > Project: Maven > Issue Type: Sub-task >Affects Versions: 3.9.0, 4.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.9.0, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7447) Several Improvements by using Stream API
[ https://issues.apache.org/jira/browse/MNG-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-7447: - Affects Version/s: 3.9.0 > Several Improvements by using Stream API > > > Key: MNG-7447 > URL: https://issues.apache.org/jira/browse/MNG-7447 > Project: Maven > Issue Type: Sub-task >Affects Versions: 3.9.0, 4.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MNG-7451) Remove public modifier from test methods / test classes
Karl Heinz Marbaise created MNG-7451: Summary: Remove public modifier from test methods / test classes Key: MNG-7451 URL: https://issues.apache.org/jira/browse/MNG-7451 Project: Maven Issue Type: Improvement Affects Versions: 4.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 4.0.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPMD-333) Add release notes documentation
[ https://issues.apache.org/jira/browse/MPMD-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516066#comment-17516066 ] Hudson commented on MPMD-333: - Build failed in Jenkins: Maven » Maven TLP » maven-pmd-plugin » master #17 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-pmd-plugin/job/master/17/ > Add release notes documentation > --- > > Key: MPMD-333 > URL: https://issues.apache.org/jira/browse/MPMD-333 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPMD-332) Support Java 18
[ https://issues.apache.org/jira/browse/MPMD-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516062#comment-17516062 ] Hudson commented on MPMD-332: - Build failed in Jenkins: Maven » Maven TLP » maven-pmd-plugin » master #16 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-pmd-plugin/job/master/16/ > Support Java 18 > --- > > Key: MPMD-332 > URL: https://issues.apache.org/jira/browse/MPMD-332 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > > With the next PMD version 6.44.0, Java 18 will be supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7436) Do not fail if there is one bad dependency
[ https://issues.apache.org/jira/browse/MNG-7436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MNG-7436: Description: We currently have a [bug-report at tycho|https://github.com/eclipse/tycho/issues/781] that complains about missing dependency resolution. It seems that a dependency with system scope but missing path triggers this (something that should be fixed of course), but I think maven should be a bit more forgiven here: Instead of failing completely, it should simply skip the "bad" dependency. If that's not feasible , in any case it should clearly indicate the causing item in the pom. was: We currently have a[ bug-report at tycho|https://github.com/eclipse/tycho/issues/781] that complains about missing dependency resolution. It seems that a dependency with system scope but missing path triggers this (something that should be fixed of course), but I think maven should be a bit more forgiven here: Instead of failing completely, it should simply skip the "bad" dependency. If that's not feasible , in any case it should clearly indicate the causing item in the pom. > Do not fail if there is one bad dependency > -- > > Key: MNG-7436 > URL: https://issues.apache.org/jira/browse/MNG-7436 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > We currently have a [bug-report at > tycho|https://github.com/eclipse/tycho/issues/781] that complains about > missing dependency resolution. > It seems that a dependency with system scope but missing path triggers this > (something that should be fixed of course), but I think maven should be a bit > more forgiven here: > Instead of failing completely, it should simply skip the "bad" dependency. If > that's not feasible , in any case it should clearly indicate the causing item > in the pom. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPMD-333) Add release notes documentation
[ https://issues.apache.org/jira/browse/MPMD-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516050#comment-17516050 ] Andreas Dangel commented on MPMD-333: - [https://gitbox.apache.org/repos/asf?p=maven-pmd-plugin.git;a=commit;h=bf1244c1be6eaa9c971c3823c6c92f634809025e] | [https://github.com/apache/maven-pmd-plugin/commit/bf1244c1be6eaa9c971c3823c6c92f634809025e] > Add release notes documentation > --- > > Key: MPMD-333 > URL: https://issues.apache.org/jira/browse/MPMD-333 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPMD-333) Add release notes documentation
[ https://issues.apache.org/jira/browse/MPMD-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel closed MPMD-333. --- Resolution: Fixed > Add release notes documentation > --- > > Key: MPMD-333 > URL: https://issues.apache.org/jira/browse/MPMD-333 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-pmd-plugin] adangel merged pull request #61: [MPMD-333] - Add release notes documentation
adangel merged pull request #61: URL: https://github.com/apache/maven-pmd-plugin/pull/61 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MPMD-332) Support Java 18
[ https://issues.apache.org/jira/browse/MPMD-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel closed MPMD-332. --- Resolution: Fixed > Support Java 18 > --- > > Key: MPMD-332 > URL: https://issues.apache.org/jira/browse/MPMD-332 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > > With the next PMD version 6.44.0, Java 18 will be supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPMD-332) Support Java 18
[ https://issues.apache.org/jira/browse/MPMD-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516049#comment-17516049 ] Andreas Dangel commented on MPMD-332: - [https://gitbox.apache.org/repos/asf?p=maven-pmd-plugin.git;a=commit;h=8cc16fbd67e104b713e1f00d55d055b9226f79a4] | [https://github.com/apache/maven-pmd-plugin/commit/8cc16fbd67e104b713e1f00d55d055b9226f79a4] > Support Java 18 > --- > > Key: MPMD-332 > URL: https://issues.apache.org/jira/browse/MPMD-332 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > > With the next PMD version 6.44.0, Java 18 will be supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-pmd-plugin] adangel merged pull request #63: [MPMD-332] - Support Java 18
adangel merged pull request #63: URL: https://github.com/apache/maven-pmd-plugin/pull/63 -- 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] [Comment Edited] (MRELEASE-1080) Maven 3.8.4 exits with non-zero status from release:perform or :prepare even when successful
[ https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506764#comment-17506764 ] Ludovic Viegas edited comment on MRELEASE-1080 at 4/1/22 3:48 PM: -- Issue created: MRELEASE-1081 Please, consider this as something very important because it prevents the usage of any Maven version above 3.8.1. was (Author: JIRAUSER286610): Issue created: MRELEASE-1081 Please, consider this a something very important because it prevents the usage of any Maven version above 3.8.1. > Maven 3.8.4 exits with non-zero status from release:perform or :prepare even > when successful > > > Key: MRELEASE-1080 > URL: https://issues.apache.org/jira/browse/MRELEASE-1080 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform, prepare >Affects Versions: 3.0.0-M5 > Environment: Windows 10, Git for Windows Bourne Again Shell, Maven > 3.8.4 >Reporter: Mirko Klemm >Assignee: Michael Osipov >Priority: Major > Labels: exit, shell > Fix For: 3.0.0-M6 > > > When doing a "release:prepare" or "release:perform", the maven process always > exits with a shell exit status of 1, even when the goal has finished with a > "BUILD SUCCESS" message, where it actually should return 0. > This doesn't seem to have been the case with 2.x versions of the plugin. > This is an important bug since it messes up using maven and the release > plugin in shell scripts. -- 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=17515971#comment-17515971
]
Michael Osipov commented on SUREFIRE-2053:
--
I think your assumption is wrong: {{.mvn/jvm.config}} has absolutely nothing to
do with the Surefire Booter which launches the tests. That's a separate JVM.
Did you make sure that fork is on?
> .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] [Moved] (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 moved MNG-7450 to SUREFIRE-2053:
---
Component/s: (was: Bootstrap & Build)
Key: SUREFIRE-2053 (was: MNG-7450)
Affects Version/s: (was: 3.8.3)
Project: Maven Surefire (was: Maven)
> .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] [Updated] (SUREFIRE-1651) JUnit5 Vintage + Maven-Failsafe + Category = ???
[
https://issues.apache.org/jira/browse/SUREFIRE-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1651:
---
Fix Version/s: waiting-for-feedback
> JUnit5 Vintage + Maven-Failsafe + Category = ???
>
>
> Key: SUREFIRE-1651
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1651
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Torsten Mingers
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: IntegrationTestJUnit5Vintage.zip
>
>
> I finally managed to switch our test infrastructure to JUnit5. Strictly
> speaking, it is the first step and the "old" tests are all still JUnit4 and
> run via the Vintage engine.
> I currently have a problem with this combination.
>
> *Some details:*
> We separate unit tests and integration tests with @Category annotations and
> then filter them out in Surefire and Failsafe. I'll add the setup below.
> Since the change to JUnit5-Vintage, filtering has stopped working and all
> tests are always running.
> In JUnit5 the filtering happens via Tags. I can not specify these in
> JUnit4-based tests.
> According to the JUnit5 documentation, the categories should continue to
> work:
> https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4-categories-support
> However, in the documentary of Surefire (or Failsafe) only tags covered:
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
> The configuration for JUnit5 tags is done in _groups_ as previously with the
> categories in JUnit4. But the configuration does not seem to work when using
> JUnit5 Vintage engine to run the tests.
> Is there a way to configure the Maven Failsafe and Surefire plugins to work
> with tags *and* categories?
> For a hint, I would be very grateful.
>
> *Configuration used*
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
> **/*.class
>
>
> net.veda.horizon.test.IntegrationTest,
> net.veda.horizon.test.IntegrationTestGraphDB,
> net.veda.horizon.test.IntegrationPermissionTest
>
>
>
>
> ...
>
>
> integrationtest
>
>
> integrationTest
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-failsafe-plugin
> 2.19.1
>
>
>
> **/*.java
>
>
> net.veda.horizon.test.IntegrationTest
>
>
> ...
>
>
>
>
>
> ...
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1879:
---
Fix Version/s: waiting-for-feedback
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Sometimes you at least see:
> {noformat}
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-1" [INFO]
> [INFO] Results:
> {noformat}
> So it looks like a timing issue?
> In comparison:
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
> https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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:all-tabpanel
]
Tibor Digana updated SUREFIRE-2029:
---
Fix Version/s: waiting-for-feedback
> 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-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:
> /usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.el7_9.x86_64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-1160.53.1.el7.x86_64", arch: "amd64",
> family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2004:
---
Fix Version/s: waiting-for-feedback
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1266) Specifying groups shouldn't require junit on classpath if no test classes
[
https://issues.apache.org/jira/browse/SUREFIRE-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1266:
---
Fix Version/s: waiting-for-feedback
> Specifying groups shouldn't require junit on classpath if no test classes
> -
>
> Key: SUREFIRE-1266
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1266
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.19.1
> Environment: Windows 7, Oracle JDK 1.8.0_40, Maven 3.3.3
>Reporter: Anders Hammar
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Test framework: junit 4.8+
> I have a scenario where we want to configure the groups parameter in a parent
> so that it doesn't have to be specified in all modules. However, not all
> modules have test classes and therefore no dependency on junit is specified
> in those projects. What then happens is that m-surefire-p fails with:
> {quote}
> groups/excludedGroups require TestNG or JUnit48+ on project test classpath
> {quote}
> This can be worked around by specifying skipTests on those projects, but it's
> a bit cumbersome.
> It would be nice if surefire could detect that there are no test classes
> (src/test/main is empty) and therefore the project should just be ignored.
> However, I guess there could be test classes in a dependency so that might
> not be as easy.
> Possibly the solution could be to not fail the surefire execution if
> groups/excludedGroups is set but TestNG or JUnit 4.8+ is not on the
> classpath, but issue a warning message and ignoring it?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7450) .mvn/jvm.config not passed to surefire (--add-opens)
[
https://issues.apache.org/jira/browse/MNG-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Schlegel updated MNG-7450:
---
Description:
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.
was:
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).
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.
> .mvn/jvm.config not passed to surefire (--add-opens)
>
>
> Key: MNG-7450
> URL: https://issues.apache.org/jira/browse/MNG-7450
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.8.3
>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
>
[jira] [Created] (MNG-7450) .mvn/jvm.config not passed to surefire (--add-opens)
Marc Schlegel created MNG-7450:
--
Summary: .mvn/jvm.config not passed to surefire (--add-opens)
Key: MNG-7450
URL: https://issues.apache.org/jira/browse/MNG-7450
Project: Maven
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 3.8.3
Reporter: Marc Schlegel
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).
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] [Updated] (MNG-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7449:
Summary: [REGRESSION] StringVisitorModelInterpolator NullPointerException
(was: StringVisitorModelInterpolator NullPointerException)
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> 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:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> 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:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> 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
[jira] [Updated] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7433: Summary: [REGRESSION] Multiple maven instances working on same source tree can lock each other (was: Multiple maven instances working on same source tree can lock each other) > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7432: Summary: [REGRESSION] Dependencies from profile not picked up via -P (was: REGRESSION in 3.8.5: Dependencies from profile not picked up via -P) > [REGRESSION] Dependencies from profile not picked up via -P > > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Priority: Critical > > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515853#comment-17515853
]
Michael Osipov commented on MSHADE-417:
---
https://github.com/apache/maven-shade-plugin/pull/73 and the merge did not care
to take care of the ticket. It is still open and unassigned to a fix version.
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
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=17515847#comment-17515847
]
Tibor Digana commented on SUREFIRE-2029:
If you use parallel Maven build, i.e. -T... , the forkNumbers may repeat.
The reason is that the idea behind Maven assumes that plugins are very isolated
and should not have any notion about the surrounding world, basically.
So I guess, the execution would be safe if you avoid using -T ...
See our integration test ForkModeIT and the pattern
{noformat}
"testValue_${surefire.threadNumber}_${surefire.forkNumber}"
{noformat}
which is resolved to testValue_1_1.
It is a combination of parallel test and parallel forks.
If the Maven API provides us with -T number on particular POm execution, we may
extend this patter. This was incremental work in passed as well.
> 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
>
> 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
>
>
>
>
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515840#comment-17515840
]
Michael Osipov commented on MSHADE-417:
---
{noformat}
c798d01138e9fecdd6422a2a8acce22ca8987924 is the first bad commit
commit c798d01138e9fecdd6422a2a8acce22ca8987924
Author: jenrryyou
Date: Sun Nov 22 23:17:56 2020 +0800
[MSHADE-378] Shade plugin changes the compression level of nested jar… (#73)
* [MSHADE-378] Shade plugin changes the compression level of nested jar
entries
* [MSHADE-378] Shade plugin changes the compression level of nested jar
entries
Co-authored-by: shaoyao
.../apache/maven/plugins/shade/DefaultShader.java | 107 +++--
.../maven/plugins/shade/DefaultShaderTest.java | 67 +
2 files changed, 165 insertions(+), 9 deletions(-)
{noformat}
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] gnodet edited a comment on pull request #703: New API with immutable model
gnodet edited a comment on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085701331 > Don;t use `Collections.unmodifiableList(xxx)`. It is vert old style - before year 2004 where the constructors where not thread safe, a typical findings with String and final fields - therefore Java changed impl for JMM of field semantics, used memory bariers at the end of constructor to make fields coherent with main mem, see JSR 133 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec/memory_model-1_0-pfd-spec.pdf?AuthParam=1648805410_6b63e95379a8c30dbb165b2da54c9d0d Sorry, I don't get the point of immutable collections vs memory semantics. I agree we should use `List.of(xxx)` if we were to raise to JDK 17, but I'm not sure there's a consensus there. What do you propose I use instead for immutable collections ?Also, in case you missed the point, I'm always using ``` list != null ? Collections.unmodifiableList( new ArrayList<>( list ) ) : Collections.emptyList() ``` in order to make sure the collections are actually safe and immutable. I can re-implement a custom unmodifiable collection to avoid the double creation, but that's more an optimisation to me rather than an actual problem. -- 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] gnodet commented on pull request #703: New API with immutable model
gnodet commented on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085701331 > Don;t use `Collections.unmodifiableList(xxx)`. It is vert old style - before year 2004 where the constructors where not thread safe, a typical findings with String and final fields - therefore Java changed impl for JMM of field semantics, used memory bariers at the end of constructor to make fields coherent with main mem, see JSR 133 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec/memory_model-1_0-pfd-spec.pdf?AuthParam=1648805410_6b63e95379a8c30dbb165b2da54c9d0d Sorry, I don't get the point of immutable collections vs memory semantics. I agree we should use `List.of(xxx)` if we were to raise to JDK 17, but I'm not sure there's a consensus there. What do you propose I use instead for immutable collections ?Also, in case you missed the point, I'm always using `list != null ? Collections.unmodifiableList( new ArrayList<>( list ) ) : Collections.emptyList()` in order to make sure the collections are actually safe and immutable. I can re-implement a custom unmodifiable collection to avoid the double creation, but that's more an optimisation to me rather than an actual problem. -- 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] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515832#comment-17515832
]
James Z.M. Gao edited comment on SUREFIRE-2004 at 4/1/22 9:52 AM:
--
[~tibordigana] Please try and save the following script as gen-bug.sh, it will
generate the reproducible bugging project on the fly. Then the you can compare
the two command result:
- ./gen-bug.sh # ok, output 100%
- ./gen-bug.sh -Daggregate # error, cannot find 100%
{code:bash}
#!/bin/sh
set -e
bug=$(mktemp -d)
trap 'rm -rf "$bug"' EXIT
mkdir -p "$bug/src/main/java" "$bug/src/test/java"
>"$bug"/src/main/java/A.java echo 'class A {}'
>"$bug"/src/test/java/ATest.java echo 'public class ATest { @org.junit.Test
>public void testFuncA() { org.junit.Assert.assertTrue(null != new A()); } }'
>"$bug"/pom.xml cat <<'END'
4.0.0
test
test
1-SNAPSHOT
junit
junit
4.13.2
test
maven-site-plugin
3.11.0
org.codehaus.mojo
exec-maven-plugin
3.0.0
exec
post-site
grep
100%
${project.reporting.outputDirectory}/surefire-report.html
maven-surefire-report-plugin
3.0.0-M5
report
END
mvn -q -f "$bug/pom.xml" post-site "$@"
{code}
was (Author: gzm55):
save the following script as gen-bug.sh, the you can compare the two command
result:
- ./gen-bug.sh # ok, output 100%
- ./gen-bug.sh -Daggregate # error, cannot find 100%
{code:bash}
#!/bin/sh
set -e
bug=$(mktemp -d)
trap 'rm -rf "$bug"' EXIT
mkdir -p "$bug/src/main/java" "$bug/src/test/java"
>"$bug"/src/main/java/A.java echo 'class A {}'
>"$bug"/src/test/java/ATest.java echo 'public class ATest { @org.junit.Test
>public void testFuncA() { org.junit.Assert.assertTrue(null != new A()); } }'
>"$bug"/pom.xml cat <<'END'
4.0.0
test
test
1-SNAPSHOT
junit
junit
4.13.2
test
maven-site-plugin
3.11.0
org.codehaus.mojo
exec-maven-plugin
3.0.0
exec
post-site
grep
100%
${project.reporting.outputDirectory}/surefire-report.html
maven-surefire-report-plugin
3.0.0-M5
report
END
mvn -q -f "$bug/pom.xml" post-site "$@"
{code}
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515832#comment-17515832
]
James Z.M. Gao commented on SUREFIRE-2004:
--
save the following script as gen-bug.sh, the you can compare the two command
result:
- ./gen-bug.sh # ok, output 100%
- ./gen-bug.sh -Daggregate # error, cannot find 100%
{code:bash}
#!/bin/sh
set -e
bug=$(mktemp -d)
trap 'rm -rf "$bug"' EXIT
mkdir -p "$bug/src/main/java" "$bug/src/test/java"
>"$bug"/src/main/java/A.java echo 'class A {}'
>"$bug"/src/test/java/ATest.java echo 'public class ATest { @org.junit.Test
>public void testFuncA() { org.junit.Assert.assertTrue(null != new A()); } }'
>"$bug"/pom.xml cat <<'END'
4.0.0
test
test
1-SNAPSHOT
junit
junit
4.13.2
test
maven-site-plugin
3.11.0
org.codehaus.mojo
exec-maven-plugin
3.0.0
exec
post-site
grep
100%
${project.reporting.outputDirectory}/surefire-report.html
maven-surefire-report-plugin
3.0.0-M5
report
END
mvn -q -f "$bug/pom.xml" post-site "$@"
{code}
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] Tibor17 edited a comment on pull request #703: New API with immutable model
Tibor17 edited a comment on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085676136 Don;t use `Collections.unmodifiableList(xxx)`. It is vert old style - before year 2004 where the constructors where not thread safe, a typical findings with String and final fields - therefore Java changed impl for JMM of field semantics, used memory bariers at the end of constructor to make fields coherent with main mem, see JSR 133 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec/memory_model-1_0-pfd-spec.pdf?AuthParam=1648805410_6b63e95379a8c30dbb165b2da54c9d0d -- 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] Tibor17 edited a comment on pull request #703: New API with immutable model
Tibor17 edited a comment on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085676136 Don;t use `Collections.unmodifiableList(xxx)`. It is vert old style - before year 2004 where the constructors where not thread safe, a typical findings with String and final fields - therefore Java changed impl for JMM of field semantics, see JSR 133 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec/memory_model-1_0-pfd-spec.pdf?AuthParam=1648805410_6b63e95379a8c30dbb165b2da54c9d0d -- 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] Tibor17 commented on pull request #703: New API with immutable model
Tibor17 commented on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085676136 Don;t use `Collections.unmodifiableList(xxx)`. It is vert old style - before year 2004 where the constructors where not thread safe, a typical founding with String and final fields - therefore Java changed impl for JMM of field semantics, see JSR 133 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec/memory_model-1_0-pfd-spec.pdf?AuthParam=1648805410_6b63e95379a8c30dbb165b2da54c9d0d -- 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] Tibor17 commented on a change in pull request #703: New API with immutable model
Tibor17 commented on a change in pull request #703:
URL: https://github.com/apache/maven/pull/703#discussion_r840364861
##
File path:
api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
##
@@ -0,0 +1,93 @@
+package org.apache.maven.api.services;
+
+/*
+ * 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.apache.maven.api.annotations.Nonnull;
+
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.List;
+import java.util.Optional;
+
+import org.apache.maven.api.Artifact;
+import org.apache.maven.api.Node;
+import org.apache.maven.api.Project;
+import org.apache.maven.api.RemoteRepository;
+import org.apache.maven.api.Session;
+
+/**
+ * Interface to manage the project during its lifecycle
+ */
+public interface ProjectManager extends Service
+{
+/**
+ * Returns the path to the resolved file in the local repository
+ * if the artifact has been resolved.
+ *
+ * @return the path of the resolved artifact
+ */
+@Nonnull
+Optional getPath( Project project );
+
+@Nonnull
+Collection getAttachedArtifacts( Project project );
+
+default void attachArtifact( Session session, Project project, Path path )
+{
+String name = path.getFileName().toString();
+int dot = name.lastIndexOf( '.' );
+String ext = dot >= 1 ? name.substring( dot + 1 ) : "";
+Artifact artifact = session.createArtifact( project.getGroupId(),
project.getArtifactId(),
+project.getVersion(), ext );
+attachArtifact( project, artifact, path );
+}
+
+default void attachArtifact( Session session, Project project, String
type, Path path )
+{
+Artifact artifact = session.createArtifact( project.getGroupId(),
project.getArtifactId(),
+project.getVersion(),
null, null, type );
+attachArtifact( project, artifact, path );
+}
+
+void attachArtifact( Project project, Artifact artifact, Path path );
+
+List getCompileSourceRoots( Project project );
+
+void addCompileSourceRoot( Project project, String sourceRoot );
+
+List getTestCompileSourceRoots( Project project );
+
+void addTestCompileSourceRoot( Project project, String sourceRoot );
+
+List getRepositories( Project project );
+
+List getResolvedDependencies( Project project, ResolutionScope
scope );
+
+Node getCollectedDependencies( Project project, ResolutionScope scope );
+
+enum ResolutionScope
Review comment:
The same here.
--
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] Tibor17 commented on a change in pull request #703: New API with immutable model
Tibor17 commented on a change in pull request #703:
URL: https://github.com/apache/maven/pull/703#discussion_r840362243
##
File path:
api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectBuilderProblem.java
##
@@ -0,0 +1,101 @@
+package org.apache.maven.api.services;
+
+/*
+ * 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.
+ */
+
+/**
+ * Describes a problem that was encountered during settings building. A
problem can either be an exception that was
+ * thrown or a simple string message. In addition, a problem carries a hint
about its source, e.g. the settings file
+ * that exhibits the problem.
+ *
+ * @author Benjamin Bentmann
+ * @author Robert Scholte
+ */
+public interface ProjectBuilderProblem
+{
+
+/**
+ * The different severity levels for a problem, in decreasing order.
+ */
+enum Severity
Review comment:
This should never happen and `Severity` should be extracted to a
separate file. It is not used inside in this class `ProjectBuilderProblem`, it
is used in public space.
--
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] Tibor17 commented on a change in pull request #703: New API with immutable model
Tibor17 commented on a change in pull request #703:
URL: https://github.com/apache/maven/pull/703#discussion_r840360344
##
File path:
api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectBuilder.java
##
@@ -0,0 +1,57 @@
+package org.apache.maven.api.services;
+
+/*
+ * 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.apache.maven.api.annotations.Nonnull;
+
+import java.nio.file.Path;
+
+import org.apache.maven.api.Session;
+import org.apache.maven.api.Artifact;
+
+public interface ProjectBuilder extends Service
+{
+
+@Nonnull
+ProjectBuilderResult build( ProjectBuilderRequest request )
+throws ProjectBuilderException, IllegalArgumentException;
+
+@Nonnull
+default ProjectBuilderResult build( @Nonnull Session session, @Nonnull
ProjectBuilderSource source )
+throws ProjectBuilderException, IllegalArgumentException
+{
+return build( ProjectBuilderRequest.build( session, source ) );
+}
+
+@Nonnull
+default ProjectBuilderResult build( @Nonnull Session session, @Nonnull
Path path )
+throws ProjectBuilderException, IllegalArgumentException
Review comment:
You can describe it in Javadoc but don't use it in method signature. See
the JDK, this is a real case.
--
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] Tibor17 commented on a change in pull request #703: New API with immutable model
Tibor17 commented on a change in pull request #703:
URL: https://github.com/apache/maven/pull/703#discussion_r840359705
##
File path:
api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectBuilder.java
##
@@ -0,0 +1,57 @@
+package org.apache.maven.api.services;
+
+/*
+ * 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.apache.maven.api.annotations.Nonnull;
+
+import java.nio.file.Path;
+
+import org.apache.maven.api.Session;
+import org.apache.maven.api.Artifact;
+
+public interface ProjectBuilder extends Service
+{
+
+@Nonnull
+ProjectBuilderResult build( ProjectBuilderRequest request )
+throws ProjectBuilderException, IllegalArgumentException;
+
+@Nonnull
+default ProjectBuilderResult build( @Nonnull Session session, @Nonnull
ProjectBuilderSource source )
+throws ProjectBuilderException, IllegalArgumentException
+{
+return build( ProjectBuilderRequest.build( session, source ) );
+}
+
+@Nonnull
+default ProjectBuilderResult build( @Nonnull Session session, @Nonnull
Path path )
+throws ProjectBuilderException, IllegalArgumentException
Review comment:
Don't use runtime exception `IllegalArgumentException` in method
signature.
--
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] [Comment Edited] (SUREFIRE-1266) Specifying groups shouldn't require junit on classpath if no test classes
[
https://issues.apache.org/jira/browse/SUREFIRE-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515787#comment-17515787
]
Ciprian Ciubotariu edited comment on SUREFIRE-1266 at 4/1/22 8:33 AM:
--
[~tibordigana] I noticed the resolution here got to won't fix so i assumed the
maintainers rejected it. I reopened the PR
was (Author: cipi):
[~tibordigana] I noticed the resolution here got to won't fix so i assumed the
maintainers rejected it
> Specifying groups shouldn't require junit on classpath if no test classes
> -
>
> Key: SUREFIRE-1266
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1266
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.19.1
> Environment: Windows 7, Oracle JDK 1.8.0_40, Maven 3.3.3
>Reporter: Anders Hammar
>Priority: Major
>
> Test framework: junit 4.8+
> I have a scenario where we want to configure the groups parameter in a parent
> so that it doesn't have to be specified in all modules. However, not all
> modules have test classes and therefore no dependency on junit is specified
> in those projects. What then happens is that m-surefire-p fails with:
> {quote}
> groups/excludedGroups require TestNG or JUnit48+ on project test classpath
> {quote}
> This can be worked around by specifying skipTests on those projects, but it's
> a bit cumbersome.
> It would be nice if surefire could detect that there are no test classes
> (src/test/main is empty) and therefore the project should just be ignored.
> However, I guess there could be test classes in a dependency so that might
> not be as easy.
> Possibly the solution could be to not fail the surefire execution if
> groups/excludedGroups is set but TestNG or JUnit 4.8+ is not on the
> classpath, but issue a warning message and ignoring it?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] gnodet edited a comment on pull request #703: New API with immutable model
gnodet edited a comment on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085598999 > Yes I saw the MDO. So the objects from the model *are* immutable, they absolutely can not be modified. So unless we raise the requirements to JDK 17, I don't see how we could actually use records / List.of(). That said, I'm not sure there's actually much difference at the end. Of course, using records would be less verbose, but given we don't have to maintain that code manually (because it's generated), I'm not sure it really matters. For the `List.of(x)` point, the model already uses immutable lists, though those use `Collections.unmodifiableList(xxx)` to be JDK 8 compatible. -- 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] gnodet edited a comment on pull request #703: New API with immutable model
gnodet edited a comment on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085598999 > Yes I saw the MDO. So the objects *are* immutable, they absolutely can not be modified. So unless we raise the requirements to JDK 17, I don't see how we could actually use records / List.of(). That said, I'm not sure there's actually much difference at the end. Of course, using records would be less verbose, but given we don't have to maintain that code manually (because it's generated), I'm not sure it really matters. For the `List.of(x)` point, the model already uses immutable lists, though those use `Collections.unmodifiableList(xxx)` to be JDK 8 compatible. -- 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] gnodet commented on pull request #703: New API with immutable model
gnodet commented on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085598999 > Yes I saw the MDO. So unless we raise the requirements to JDK 17, I don't see how we could actually use records / List.of(). That said, I'm not sure there's actually much difference at the end. Of course, using records would be less verbose, but given we don't have to maintain that code manually (because it's generated), I'm not sure it really matters. For the `List.of(x)` point, the model already uses immutable lists, though those use `Collections.unmodifiableList(xxx)` to be JDK 8 compatible. -- 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-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=17515793#comment-17515793
]
Falko Modler commented on SUREFIRE-2029:
[~tibordigana] do you have an idea what might have broken this?
> 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
>
> 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:
> /usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.el7_9.x86_64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-1160.53.1.el7.x86_64", arch: "amd64",
> family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] Tibor17 commented on pull request #703: New API with immutable model
Tibor17 commented on pull request #703: URL: https://github.com/apache/maven/pull/703#issuecomment-1085592833 Yes I saw the MDO. -- 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-1266) Specifying groups shouldn't require junit on classpath if no test classes
[
https://issues.apache.org/jira/browse/SUREFIRE-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515787#comment-17515787
]
Ciprian Ciubotariu commented on SUREFIRE-1266:
--
[~tibordigana] I noticed the resolution here got to won't fix so i assumed the
maintainers rejected it
> Specifying groups shouldn't require junit on classpath if no test classes
> -
>
> Key: SUREFIRE-1266
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1266
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.19.1
> Environment: Windows 7, Oracle JDK 1.8.0_40, Maven 3.3.3
>Reporter: Anders Hammar
>Priority: Major
>
> Test framework: junit 4.8+
> I have a scenario where we want to configure the groups parameter in a parent
> so that it doesn't have to be specified in all modules. However, not all
> modules have test classes and therefore no dependency on junit is specified
> in those projects. What then happens is that m-surefire-p fails with:
> {quote}
> groups/excludedGroups require TestNG or JUnit48+ on project test classpath
> {quote}
> This can be worked around by specifying skipTests on those projects, but it's
> a bit cumbersome.
> It would be nice if surefire could detect that there are no test classes
> (src/test/main is empty) and therefore the project should just be ignored.
> However, I guess there could be test classes in a dependency so that might
> not be as easy.
> Possibly the solution could be to not fail the surefire execution if
> groups/excludedGroups is set but TestNG or JUnit 4.8+ is not on the
> classpath, but issue a warning message and ignoring it?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] gnodet commented on pull request #703: New API with immutable model
gnodet commented on pull request #703:
URL: https://github.com/apache/maven/pull/703#issuecomment-1085591083
> If we want to use immutable objects, we should use Java Records. We still
do not have Valhalla ready. The developers often do not understand Java Memory
Model and there is no guarantee that they would not make a mistake when they
update any immutable object. The developers usually would not understand why
ConcurrentLinkedQueue is preferable over ArrayList and `List.copyOf()` is ideal
https://docs.oracle.com/javase/10/docs/api/java/util/List.html#copyOf(java.util.Collection),
and so we should use `List.copyOf()` which means that we should switch the
project to Java 10 - bad luck! Nobody would accept Java 10, I guess.
>
> The immutable object should be fetched with data via a builder in
constructor. `MavenProject and MavenProjectBuilder composition`
>
> ```
> public record MavenProject(MavenProjectBuilder builder) {
>
> MavenProject {
> dependencies = List.copyOf(builder.getDependencies());
> ...
> ...
> ...
> }
> }
> ```
Have you had a look at the generated code or are those just general comments
about java records / immutable objects ?
--
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] CMoH opened a new pull request #388: [SUREFIRE-1266] Skip junit dependency check if module has no tests to run
CMoH opened a new pull request #388: URL: https://github.com/apache/maven-surefire/pull/388 Don't require users to add junit dependencies on all projects when using groups in surefire/failsafe at the reactor-level This is a proposal on how to achieve this effect, as described in the issue. Please guide me if you have expectations on how to structure this check in a better way (such as a separate method instead of a boolean?) I have prepared a demo test-case project at https://github.com/CMoH/surefire1266-sample to illustrate the situation and the fix. I can add it to the `surefire-it` folder if you find it worthwhile - maybe in a form more suitable for that purpose. The current incarnation is intended to depict the situation I am faced with, the one that motivated this contribution. -- 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] Tibor17 edited a comment on pull request #703: New API with immutable model
Tibor17 edited a comment on pull request #703:
URL: https://github.com/apache/maven/pull/703#issuecomment-1085568686
If we want to use immutable objects, we should use Java Records. We still do
not have Valhalla ready.
The developers often do not understand Java Memory Model and there is no
guarantee that they would not make a mistake when they update any immutable
object. The developers usually would not understand why ConcurrentLinkedQueue
is preferable over ArrayList and `List.copyOf()` is ideal
https://docs.oracle.com/javase/10/docs/api/java/util/List.html#copyOf(java.util.Collection),
and so we should use `List.copyOf()` which means that we should switch the
project to Java 10 - bad luck! Nobody would accept Java 10, I guess.
The immutable object should be fetched with data via a builder in
constructor.
`MavenProject and MavenProjectBuilder composition`
```
public record MavenProject(MavenProjectBuilder builder) {
MavenProject {
dependencies = List.copyOf(builder.getDependencies());
...
...
...
}
}
```
--
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] Tibor17 edited a comment on pull request #703: New API with immutable model
Tibor17 edited a comment on pull request #703:
URL: https://github.com/apache/maven/pull/703#issuecomment-1085568686
If we want to use immutable objects, we should use Java Records. We still do
not have Valhalla ready.
The developers often do not understand Java Memory Model and there is no
guarantee that they would not make a mistake when they update any immutable
object. The developers usually would not understand why ConcurrentLinkedQueue
is preferable over ArrayList and `List.copyOf()` is ideal
https://docs.oracle.com/javase/10/docs/api/java/util/List.html#copyOf(java.util.Collection),
and so we should use `List.copyOf()` which means that we should switch the
project to Java 10 - bad luck! Nobody would accept Java 10, I guess.
The immutable object should be fetched with data in constructor via a
builder.
`MavenProject and MavenProjectBuilder composition`
```
public record MavenProject(MavenProjectBuilder builder) {
MavenProject {
dependencies = List.copyOf(builder.getDependencies());
...
...
...
}
}
```
--
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] Tibor17 edited a comment on pull request #703: New API with immutable model
Tibor17 edited a comment on pull request #703:
URL: https://github.com/apache/maven/pull/703#issuecomment-1085568686
If we want to use immutable objects, we should use Java Records. We still do
not have Valhalla ready.
The developers often do not understand Java Memory Model and there is no
guarantee that they would not make a mistake when they update any immutable
object. The developers usually would not understand why ConcurrentLinkedQueue
is preferable over ArrayList and `List.copyOf()` is ideal
https://docs.oracle.com/javase/10/docs/api/java/util/List.html#copyOf(java.util.Collection),
and so we should use `List.copyOf()` which means that we should switch the
project to Java 10 - bad luck! Nobody would accept Java 10, I guess.
The immutable object should be fetched with data in constructor via a
builder.
`MavenProject and MavenProjectBuilder composition`
```
public record MavenProject(MavenProjectBuilder builder) {
public MavenProject {
dependencies = List.copyOf(builder.getDependencies());
...
...
...
}
}
```
--
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-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515778#comment-17515778
]
Alexander Kriegisch commented on SUREFIRE-2004:
---
[~tibordigana], I am not sure if you were asking me or James for a reproducible
project. But actually, it is super trivial: Just use any single-module JAR
project and activate the aggregation option.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] Tibor17 commented on pull request #703: New API with immutable model
Tibor17 commented on pull request #703:
URL: https://github.com/apache/maven/pull/703#issuecomment-1085568686
If we want to use immutable objects, we should use Java Records. We still do
not have Valhalla ready.
The developers often do not understand Java Memory Model and there is no
guarantee that they would not make a mistake when they update any immutable
object. The developers usually would not understand why ConcurrentLinkedQueue
is preferable over ArrayList and `List.copyOf()` is ideal
https://docs.oracle.com/javase/10/docs/api/java/util/List.html#copyOf(java.util.Collection),
and so we should use `List.copyOf()` which means that we would switch the
project to Java 10 - bad luck! Nobody would accept Java 10, I guess.
The immutable object should be fetched with data in constructor via a
builder.
`MavenProject and MavenProjectBuilder composition`
```
record MavenProject(MavenProjectBuilder builder) {
public MavenProject {
dependencies = List.copyOf(builder.getDependencies());
...
...
...
}
}
```
--
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] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515766#comment-17515766 ] Alvaro Sanchez-Mariscal commented on MCOMPILER-391: --- Is the Maven team still interested in fixing this issue? If so, I could help to put together a PR, test it, or whatever else that is needed. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Priority: Blocker > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-install-plugin] slawekjaranowski commented on a change in pull request #25: [MINSTALL-173] Cleanup of configuration with parent 35
slawekjaranowski commented on a change in pull request #25:
URL:
https://github.com/apache/maven-install-plugin/pull/25#discussion_r840302054
##
File path: pom.xml
##
@@ -185,27 +207,17 @@
org.apache.maven.plugins
maven-invoker-plugin
- 3.2.2
-
${project.build.directory}/it
true
*/pom.xml
*/non-default-pom.xml
-setup
-verify
-
${project.build.directory}/local-repo
-src/it/settings.xml
true
clean
install
-
-
- ${https.protocols}
Review comment:
Identical configuration is in parent, so is not needed because is
inherited and of course is only needed when we want build by jdk 1.7
--
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
