[GitHub] [maven] laeubi commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1073188594 > I think that writing "restoring the old behavior from Maven 3.8.4" should have made it clear that I already knew that. Sure but if you simply "do not really care" the easiest and fastest way is using 3.8.4. For 3.8.5 support for additional Readers was added because there are people who care, and applying a fix that would only "restoring the old behavior" (that was already broken but probably never noticed) won't help much. I also don't see that the fix is controversial just that @michael-o want to better understand the cause, so if you can provide additional information why your build fails e.g. by providing a minimal reproducer, integration or unit test or you can confirm that it is the same problem described by @famod then it might help to make more progress 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
[jira] [Comment Edited] (MNG-7433) 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:comment-tabpanel&focusedCommentId=17508563#comment-17508563
]
Dan Tran edited comment on MNG-7433 at 3/20/22, 7:49 AM:
-
The below comment block in interesting
{code:java}
/**
* Aggregating mojo executions (possibly) modify all MavenProjects,
including those that are currently in use
* by concurrently running mojo executions. To prevent race conditions, an
aggregating execution will block
* all other executions until finished.
* We also lock on a given project to forbid a forked lifecycle to be
executed concurrently with the project.
* TODO: ideally, the builder should take care of the ordering in a smarter
way
* TODO: and concurrency issues fixed with MNG-7157
*/
private static class ProjectLock implements AutoCloseable
{code}
Wonder if running invoke-plugin consider as a 'aggregated project' and its
locks other modules at reactor from running
was (Author: dantran):
The below comment block in interesting
{code:java}
/**
* Aggregating mojo executions (possibly) modify all MavenProjects,
including those that are currently in use
* by concurrently running mojo executions. To prevent race conditions, an
aggregating execution will block
* all other executions until finished.
* We also lock on a given project to forbid a forked lifecycle to be
executed concurrently with the project.
* TODO: ideally, the builder should take care of the ordering in a smarter
way
* TODO: and concurrency issues fixed with MNG-7157
*/
private static class ProjectLock implements AutoCloseable
{code}
> 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] [Commented] (MNG-7433) 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:comment-tabpanel&focusedCommentId=17509393#comment-17509393 ] Dan Tran commented on MNG-7433: --- [~gnodet] please advice > 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] [Commented] (SUREFIRE-2037) Allow for surefire-junit-platform's TestMethodFilter to support custom TestSources
[
https://issues.apache.org/jira/browse/SUREFIRE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509397#comment-17509397
]
Tibor Digana commented on SUREFIRE-2037:
[~crizzis_dna]
My problem is that we have opened SPI interface for TestSources but we did not
implement it.
The {{surefire-junit-platform}} with classes and methods was the first step to
introduce this provider into the world because that time there was 100% users
with test classes.
If we want to continue with supporting more than classes, we have only one
option to support the rest of TestSources in this project and not outside of
the plugin or project - behind SPI. It is not realistic situation that the
users will implement it by themselves. They do not have time to do it. They
want to specify a new version of plugin in the POM or they use new version of
Maven which has this version in default bindings and that's whole business. The
main goal of the plugin is to execute the tests but it is not realistic to
shift it to somewhere and make this basic functionality plugin-able again apart.
So yes, if we want to continue with multiple TestSources then we should
implement them inside in this project and not outside. This should be our work.
> Allow for surefire-junit-platform's TestMethodFilter to support custom
> TestSources
> --
>
> Key: SUREFIRE-2037
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2037
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Krzysztof Sierszeń
>Priority: Minor
>
> Since JUnit 5 allows for custom {{{}TestSource{}}}s to be configured,
> {{TestMethodFilter}} could provide a way for those sources to be recognized
> and filterable. This way, custom method sources will enjoy the same filtering
> capabilities that method sources do.
> For now, this change specifically targets ArchUnit's {{FieldSource}}, and I'm
> planning to use the solution provided to solve [the following
> issue|https://github.com/TNG/ArchUnit/issues/641].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2037) Allow for surefire-junit-platform's TestMethodFilter to support custom TestSources
[
https://issues.apache.org/jira/browse/SUREFIRE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509399#comment-17509399
]
Tibor Digana commented on SUREFIRE-2037:
The next big problem is that we have more and more code but I did not see
integration tests without SPI, means with TestSource - field, directory,
script, etc.
There must be unit tests. I have paid very big attention to cover this project
with unit tests and we should continue with this attitude.
> Allow for surefire-junit-platform's TestMethodFilter to support custom
> TestSources
> --
>
> Key: SUREFIRE-2037
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2037
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Krzysztof Sierszeń
>Priority: Minor
>
> Since JUnit 5 allows for custom {{{}TestSource{}}}s to be configured,
> {{TestMethodFilter}} could provide a way for those sources to be recognized
> and filterable. This way, custom method sources will enjoy the same filtering
> capabilities that method sources do.
> For now, this change specifically targets ArchUnit's {{FieldSource}}, and I'm
> planning to use the solution provided to solve [the following
> issue|https://github.com/TNG/ArchUnit/issues/641].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-wrapper] slawekjaranowski merged pull request #36: [MWRAPPER-62] Upgrade Parent to 35
slawekjaranowski merged pull request #36: URL: https://github.com/apache/maven-wrapper/pull/36 -- 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] (MWRAPPER-62) Upgrade Parent to 35
[ https://issues.apache.org/jira/browse/MWRAPPER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MWRAPPER-62. --- Fix Version/s: 3.1.1 3.2.0 Resolution: Fixed > Upgrade Parent to 35 > > > Key: MWRAPPER-62 > URL: https://issues.apache.org/jira/browse/MWRAPPER-62 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1, 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-62) Upgrade Parent to 35
[ https://issues.apache.org/jira/browse/MWRAPPER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509407#comment-17509407 ] ASF GitHub Bot commented on MWRAPPER-62: slawekjaranowski merged pull request #36: URL: https://github.com/apache/maven-wrapper/pull/36 -- 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 > Upgrade Parent to 35 > > > Key: MWRAPPER-62 > URL: https://issues.apache.org/jira/browse/MWRAPPER-62 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-62) Upgrade Parent to 35
[ https://issues.apache.org/jira/browse/MWRAPPER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509408#comment-17509408 ] Hudson commented on MWRAPPER-62: Build succeeded in Jenkins: Maven » Maven TLP » maven-wrapper » master #10 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/master/10/ > Upgrade Parent to 35 > > > Key: MWRAPPER-62 > URL: https://issues.apache.org/jira/browse/MWRAPPER-62 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1, 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] hboutemy commented on a change in pull request #676: MNG 7413
hboutemy commented on a change in pull request #676: URL: https://github.com/apache/maven/pull/676#discussion_r830588847 ## File path: maven-model/src/main/mdo/maven.mdo ## @@ -642,11 +642,11 @@ - + BuildBase 3.0.0+ PluginConfiguration - Generic informations for a build. + Build configuration in a profile. Review comment: yes, this is what I discovered: the split between BuildBase and Build does not exist for some abstract reason to introduce class inheritance, but because BuildBase is used in profile, then define everything that can be overridden in profile and Build is the full main build element (with additional sourceDirectory, and so on) I did not expect to discover that... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] hboutemy merged pull request #34: add NOTICE file with attribution of initial maven-wrapper module
hboutemy merged pull request #34: URL: https://github.com/apache/maven-wrapper/pull/34 -- 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] (MWRAPPER-62) Upgrade Parent to 35
[ https://issues.apache.org/jira/browse/MWRAPPER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-62: Fix Version/s: (was: 3.2.0) > Upgrade Parent to 35 > > > Key: MWRAPPER-62 > URL: https://issues.apache.org/jira/browse/MWRAPPER-62 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2039) Skipped test classes are getting into the non-skipped test classes reports
Semyon Danilov created SUREFIRE-2039:
Summary: Skipped test classes are getting into the non-skipped
test classes reports
Key: SUREFIRE-2039
URL: https://issues.apache.org/jira/browse/SUREFIRE-2039
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.0.0-M5
Reporter: Semyon Danilov
Consider a simple scenario, two test classes, `ATest` and `BTest`, one
Disabled and one not respectively, each has three test methods. After running
`mvn surefire:test` the report will indicate that 4 tests were run and one of
them was skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.BTest
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.062
s - in org.example.test.BTest
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
{noformat}
And if we enable ATest and disable BTest, then report will only mention running
three tests, none skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.ATest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 s
- in org.example.test.ATest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{noformat}
This behavior is the result of the way how
`org.apache.maven.plugin.surefire.report.TestSetRunListener` handles skipped
test. It adds them to the `detailsForThis` and only print after test set is
finished which happens when a non-disabled test set is finished thus adding
skipped test results to the statistics of a non-skipped test set. And, of
course, if the disabled test is ran after the non-disabled test, it won't be
reported at all.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2039) Skipped test classes are getting into the non-skipped test classes reports
[
https://issues.apache.org/jira/browse/SUREFIRE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated SUREFIRE-2039:
-
Description:
Consider a simple scenario, two test classes, `ATest` and `BTest`, one
Disabled and one not respectively, each has three test methods. After running
`mvn surefire:test` the report will indicate that 4 tests were run and one of
them was skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.BTest
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.062
s - in org.example.test.BTest
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
{noformat}
And if we enable ATest and disable BTest, then report will only mention running
three tests, none skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.ATest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 s
- in org.example.test.ATest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{noformat}
This behavior is the result of the way how
`org.apache.maven.plugin.surefire.report.TestSetRunListener` handles skipped
test. It adds them to the `detailsForThis` and only print after test set is
finished which happens when a non-disabled test set is finished thus adding
skipped test results to the statistics of a non-skipped test set. And, of
course, if the disabled test is ran after the non-disabled test, it won't be
reported at all.
The reproducer can be found here:
https://github.com/SammyVimesFiledIssues/SUREFIRE-2039
was:
Consider a simple scenario, two test classes, `ATest` and `BTest`, one
Disabled and one not respectively, each has three test methods. After running
`mvn surefire:test` the report will indicate that 4 tests were run and one of
them was skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.BTest
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.062
s - in org.example.test.BTest
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
{noformat}
And if we enable ATest and disable BTest, then report will only mention running
three tests, none skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.ATest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 s
- in org.example.test.ATest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{noformat}
This behavior is the result of the way how
`org.apache.maven.plugin.surefire.report.TestSetRunListener` handles skipped
test. It adds them to the `detailsForThis` and only print after test set is
finished which happens when a non-disabled test set is finished thus adding
skipped test results to the statistics of a non-skipped test set. And, of
course, if the disabled test is ran after the non-disabled test, it won't be
reported at all.
> Skipped test classes are getting into the non-skipped test classes reports
> --
>
> Key: SUREFIRE-2039
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2039
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
>Reporter: Semyon Danilov
>Priority: Major
>
> Consider a simple scenario, two test classes, `ATest` and `BTest`, one
> Disabled and one not respectively, each has three test methods. After running
> `mvn surefire:test` the report will indicate that 4 tests were run and one of
> them was skipped:
> {noformat}
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.test.BTest
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
> 0.062 s - in org.example.test.BTest
> [INFO]
> [INFO] Results:
> [INFO]
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
> {noformat}
> And if we enable ATest and disable BTest, then report will only mention
> running three tests, none skipped:
> {noformat}
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.test.ATest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079
> s - in org.example.test.ATest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> This behavior is the result of the way how
> `org.apache.maven.plugin.surefire.report.TestSetRunListener` handles skipped
> test. It adds them to the `detail
[GitHub] [maven-surefire] SammyVimes opened a new pull request #493: SUREFIRE-2039 Fix skipped test reporting
SammyVimes opened a new pull request #493: URL: https://github.com/apache/maven-surefire/pull/493 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-2039) Skipped test classes are getting into the non-skipped test classes reports
[
https://issues.apache.org/jira/browse/SUREFIRE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated SUREFIRE-2039:
-
Description:
Consider a simple scenario, two test classes, *ATest* and *BTest*, one
+Disabled+ and one not respectively, each has three test methods. After running
_mvn surefire:test_ the report will indicate that 4 tests were run and one of
them was skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.BTest
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.062
s - in org.example.test.BTest
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
{noformat}
And if we enable *ATest* and disable *BTest*, then the report will only mention
running three tests, none skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.ATest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 s
- in org.example.test.ATest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{noformat}
This behavior is the result of the way how
*org.apache.maven.plugin.surefire.report.TestSetRunListener* handles skipped
tests. It adds them to the *detailsForThis* and only prints after the test set
is finished which happens when a non-disabled test set is finished thus adding
skipped test results to the statistics of a non-skipped test set. And, of
course, if the disabled test is ran after the non-disabled test, it won't be
reported at all.
The reproducer can be found here:
https://github.com/SammyVimesFiledIssues/SUREFIRE-2039
was:
Consider a simple scenario, two test classes, `ATest` and `BTest`, one
Disabled and one not respectively, each has three test methods. After running
`mvn surefire:test` the report will indicate that 4 tests were run and one of
them was skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.BTest
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.062
s - in org.example.test.BTest
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
{noformat}
And if we enable ATest and disable BTest, then report will only mention running
three tests, none skipped:
{noformat}
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.test.ATest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 s
- in org.example.test.ATest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{noformat}
This behavior is the result of the way how
`org.apache.maven.plugin.surefire.report.TestSetRunListener` handles skipped
test. It adds them to the `detailsForThis` and only print after test set is
finished which happens when a non-disabled test set is finished thus adding
skipped test results to the statistics of a non-skipped test set. And, of
course, if the disabled test is ran after the non-disabled test, it won't be
reported at all.
The reproducer can be found here:
https://github.com/SammyVimesFiledIssues/SUREFIRE-2039
> Skipped test classes are getting into the non-skipped test classes reports
> --
>
> Key: SUREFIRE-2039
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2039
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
>Reporter: Semyon Danilov
>Priority: Major
>
> Consider a simple scenario, two test classes, *ATest* and *BTest*, one
> +Disabled+ and one not respectively, each has three test methods. After
> running _mvn surefire:test_ the report will indicate that 4 tests were run
> and one of them was skipped:
> {noformat}
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.test.BTest
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
> 0.062 s - in org.example.test.BTest
> [INFO]
> [INFO] Results:
> [INFO]
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
> {noformat}
> And if we enable *ATest* and disable *BTest*, then the report will only
> mention running three tests, none skipped:
> {noformat}
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.test.ATest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079
> s - in org.example.test.ATest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> This behavior is the result of the way how
[jira] [Commented] (SUREFIRE-2039) Skipped test classes are getting into the non-skipped test classes reports
[
https://issues.apache.org/jira/browse/SUREFIRE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509454#comment-17509454
]
Semyon Danilov commented on SUREFIRE-2039:
--
I have a naive approach patch for solving this issue:
https://github.com/apache/maven-surefire/pull/493 but, as I've written in the
description for the PR, I don't really like it and some feedback from the
maintainers can help me improve it.
> Skipped test classes are getting into the non-skipped test classes reports
> --
>
> Key: SUREFIRE-2039
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2039
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
>Reporter: Semyon Danilov
>Priority: Major
>
> Consider a simple scenario, two test classes, *ATest* and *BTest*, one
> +Disabled+ and one not respectively, each has three test methods. After
> running _mvn surefire:test_ the report will indicate that 4 tests were run
> and one of them was skipped:
> {noformat}
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.test.BTest
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
> 0.062 s - in org.example.test.BTest
> [INFO]
> [INFO] Results:
> [INFO]
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1
> {noformat}
> And if we enable *ATest* and disable *BTest*, then the report will only
> mention running three tests, none skipped:
> {noformat}
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.test.ATest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079
> s - in org.example.test.ATest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> This behavior is the result of the way how
> *org.apache.maven.plugin.surefire.report.TestSetRunListener* handles skipped
> tests. It adds them to the *detailsForThis* and only prints after the test
> set is finished which happens when a non-disabled test set is finished thus
> adding skipped test results to the statistics of a non-skipped test set. And,
> of course, if the disabled test is ran after the non-disabled test, it won't
> be reported at all.
> The reproducer can be found here:
> https://github.com/SammyVimesFiledIssues/SUREFIRE-2039
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] basil commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
basil commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1073294198 > so if you can provide Sorry, I lack the time and interest to pursue this further. I have already reverted back to Maven 3.8.4. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-311) Upgrade Maven JXR Plugin from 3.1.1 to 3.2.0
Slawomir Jaranowski created MPOM-311: Summary: Upgrade Maven JXR Plugin from 3.1.1 to 3.2.0 Key: MPOM-311 URL: https://issues.apache.org/jira/browse/MPOM-311 Project: Maven POMs Issue Type: Dependency upgrade Components: maven Reporter: Slawomir Jaranowski Fix For: MAVEN-36 h1. Release Notes - Maven JXR - Version 3.2.0 h2. Bug * [JXR-164] - Full path to local code sources in page title h2. Task * [JXR-162] - Lift Minimum Java to Java 8 h2. Dependency upgrade * [JXR-157] - Upgrade Velocity templating engine * [JXR-163] - Require Maven 3.2.5+ * [JXR-165] - Upgrade Maven Reporting to 3.1.0 * [JXR-167] - Upgrade Parent to 35 * [JXR-168] - Dependency upgrade and cleanup -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #445: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski commented on pull request #445: URL: https://github.com/apache/maven-surefire/pull/445#issuecomment-1073310665 @Tibor17 - ping -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #399: [SUREFIRE-1963] Detecting multiple test-frameworks
slawekjaranowski commented on pull request #399: URL: https://github.com/apache/maven-surefire/pull/399#issuecomment-1073311868 @Tibor17 There is IT test - surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1963MultipleFrameworkIT.java Is it not enough? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (SUREFIRE-2000) Classpath contains redundant JAR artifacts if ShadeFire provider is active
[ https://issues.apache.org/jira/browse/SUREFIRE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed SUREFIRE-2000. - Fix Version/s: (was: 3.0.0-M6) Resolution: Not A Bug > Classpath contains redundant JAR artifacts if ShadeFire provider is active > -- > > Key: SUREFIRE-2000 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2000 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, > surefire-shadefire >Affects Versions: 3.0.0-M5 >Reporter: Tibor Digana >Assignee: Slawomir Jaranowski >Priority: Major > Attachments: MANIFEST.MF-for-M4, MANIFEST.MF-for-M5, > MANIFEST.MF-for-M6, junit5-runner.tgz > > > There are extra more artifacts than necessary on the classpath if ShadeFire > provider is used. This may cause new conflicts if testing Surefire itself. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #491: [SUREFIRE-2038] Upgrade Maven Parent to 35
slawekjaranowski commented on pull request #491: URL: https://github.com/apache/maven-surefire/pull/491#issuecomment-1073312273 ping for review -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MPOM-294) Remove surefire from Maven site reports
[ https://issues.apache.org/jira/browse/MPOM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MPOM-294: Assignee: (was: Slawomir Jaranowski) > Remove surefire from Maven site reports > --- > > Key: MPOM-294 > URL: https://issues.apache.org/jira/browse/MPOM-294 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Reporter: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPOM-296) Remove pmd from Maven site reports
[ https://issues.apache.org/jira/browse/MPOM-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MPOM-296: Assignee: (was: Slawomir Jaranowski) > Remove pmd from Maven site reports > -- > > Key: MPOM-296 > URL: https://issues.apache.org/jira/browse/MPOM-296 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Reporter: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPOM-295) Remove checkstyle from Maven site reports
[ https://issues.apache.org/jira/browse/MPOM-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MPOM-295: Assignee: (was: Slawomir Jaranowski) > Remove checkstyle from Maven site reports > - > > Key: MPOM-295 > URL: https://issues.apache.org/jira/browse/MPOM-295 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Reporter: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPOM-297) Remove taglist from Maven site reports
[ https://issues.apache.org/jira/browse/MPOM-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MPOM-297: Assignee: (was: Slawomir Jaranowski) > Remove taglist from Maven site reports > -- > > Key: MPOM-297 > URL: https://issues.apache.org/jira/browse/MPOM-297 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Reporter: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPOM-299) Remove invoker from Maven site reports
[ https://issues.apache.org/jira/browse/MPOM-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MPOM-299: Assignee: (was: Slawomir Jaranowski) > Remove invoker from Maven site reports > -- > > Key: MPOM-299 > URL: https://issues.apache.org/jira/browse/MPOM-299 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Reporter: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2040) When moving from JUnit 4 to JUnit 5, with some JUnit 4 tests remaining, Surefire is unable to execute a test suite from the command line
David M. Karr created SUREFIRE-2040:
---
Summary: When moving from JUnit 4 to JUnit 5, with some JUnit 4
tests remaining, Surefire is unable to execute a test suite from the command
line
Key: SUREFIRE-2040
URL: https://issues.apache.org/jira/browse/SUREFIRE-2040
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support
Affects Versions: 3.0.0-M5
Reporter: David M. Karr
My organization is in the process of moving their SpringBoot Maven builds from
JUnit 4 to JUnit 5. Our "default" build runs all the unit tests. We also have
"component tests" and "integration tests" that are specified in a "TestSuite"
class. The build process specifies the name of the suite class on the command
line with "-Dtest=ComponentTestSuite", for instance. Before the move to JUnit
5, this all worked fine.
In the move to JUnit 5, I modified ComponentTestSuite to be like this:
import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;
@Suite
@SelectClasses(NoteResourceCT.class)
public class ComponentTestSuite {
}
Now, when I run "mvn -Dtest=ComponentTestSuite test", it says the following:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) on
project ...: No tests were executed! (Set -DfailIfNoTests=false to ignore this
error.) -> [Help 1]
There are no other messages.
My pom.xml basically looks like this:
org.junit
junit-bom
5.8.2
pom
import
org.springframework.boot
spring-boot-starter-test
test
org.mockito
mockito-junit-jupiter
4.4.0
test
junit
junit
4.13.2
test
org.junit.platform
junit-platform-suite-api
...
...
maven-surefire-plugin
3.0.0-M5
false
true
...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SUREFIRE-2040) When moving from JUnit 4 to JUnit 5, with some JUnit 4 tests remaining, Surefire is unable to execute a test suite from the command line
[
https://issues.apache.org/jira/browse/SUREFIRE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2040:
--
Assignee: Tibor Digana
> When moving from JUnit 4 to JUnit 5, with some JUnit 4 tests remaining,
> Surefire is unable to execute a test suite from the command line
>
>
> Key: SUREFIRE-2040
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2040
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: David M. Karr
>Assignee: Tibor Digana
>Priority: Major
>
> My organization is in the process of moving their SpringBoot Maven builds
> from JUnit 4 to JUnit 5. Our "default" build runs all the unit tests. We
> also have "component tests" and "integration tests" that are specified in a
> "TestSuite" class. The build process specifies the name of the suite class
> on the command line with "-Dtest=ComponentTestSuite", for instance. Before
> the move to JUnit 5, this all worked fine.
> In the move to JUnit 5, I modified ComponentTestSuite to be like this:
> import org.junit.platform.suite.api.SelectClasses;
> import org.junit.platform.suite.api.Suite;
> @Suite
> @SelectClasses(NoteResourceCT.class)
> public class ComponentTestSuite {
> }
> Now, when I run "mvn -Dtest=ComponentTestSuite test", it says the following:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project ...: No tests were executed! (Set -DfailIfNoTests=false to ignore
> this error.) -> [Help 1]
> There are no other messages.
> My pom.xml basically looks like this:
>
> ...
>
>
>
> org.junit
> junit-bom
> 5.8.2
> pom
> import
>
>
>
>
>
> org.springframework.boot
> spring-boot-starter-test
> test
>
>
> org.mockito
> mockito-junit-jupiter
> 4.4.0
> test
>
>
> junit
> junit
> 4.13.2
> test
>
>
> org.junit.platform
> junit-platform-suite-api
>
> ...
>
>
>
> ...
>
> maven-surefire-plugin
> 3.0.0-M5
>
> false
>
> true
>
>
> ...
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2040) When moving from JUnit 4 to JUnit 5, with some JUnit 4 tests remaining, Surefire is unable to execute a test suite from the command line
[
https://issues.apache.org/jira/browse/SUREFIRE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2040:
---
Fix Version/s: 3.0.0-M6
> When moving from JUnit 4 to JUnit 5, with some JUnit 4 tests remaining,
> Surefire is unable to execute a test suite from the command line
>
>
> Key: SUREFIRE-2040
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2040
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: David M. Karr
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> My organization is in the process of moving their SpringBoot Maven builds
> from JUnit 4 to JUnit 5. Our "default" build runs all the unit tests. We
> also have "component tests" and "integration tests" that are specified in a
> "TestSuite" class. The build process specifies the name of the suite class
> on the command line with "-Dtest=ComponentTestSuite", for instance. Before
> the move to JUnit 5, this all worked fine.
> In the move to JUnit 5, I modified ComponentTestSuite to be like this:
> import org.junit.platform.suite.api.SelectClasses;
> import org.junit.platform.suite.api.Suite;
> @Suite
> @SelectClasses(NoteResourceCT.class)
> public class ComponentTestSuite {
> }
> Now, when I run "mvn -Dtest=ComponentTestSuite test", it says the following:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project ...: No tests were executed! (Set -DfailIfNoTests=false to ignore
> this error.) -> [Help 1]
> There are no other messages.
> My pom.xml basically looks like this:
>
> ...
>
>
>
> org.junit
> junit-bom
> 5.8.2
> pom
> import
>
>
>
>
>
> org.springframework.boot
> spring-boot-starter-test
> test
>
>
> org.mockito
> mockito-junit-jupiter
> 4.4.0
> test
>
>
> junit
> junit
> 4.13.2
> test
>
>
> org.junit.platform
> junit-platform-suite-api
>
> ...
>
>
>
> ...
>
> maven-surefire-plugin
> 3.0.0-M5
>
> false
>
> true
>
>
> ...
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-7433) 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:comment-tabpanel&focusedCommentId=17508424#comment-17508424 ] Dan Tran edited comment on MNG-7433 at 3/20/22, 7:49 PM: - I also tried: * switch apache maven-invoker to run sonar:sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * invoke a different goal such as compile, or just a simple sleep instead of sonar:sonar * latest 3.9.0 from source A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock was (Author: dantran): I also tried: * switch apache maven-invoker to run sonar:sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * invoke a different goal ( compile instead of sonar:sonar) * latest 3.9.0 from source Possible that the lock is on stdout/stderr stream? A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock > 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] (SUREFIRE-2040) No tests executed with junit-platform-suite and -Dtest=TestSuite
[
https://issues.apache.org/jira/browse/SUREFIRE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2040:
---
Summary: No tests executed with junit-platform-suite and -Dtest=TestSuite
(was: When moving from JUnit 4 to JUnit 5, with some JUnit 4 tests remaining,
Surefire is unable to execute a test suite from the command line)
> No tests executed with junit-platform-suite and -Dtest=TestSuite
>
>
> Key: SUREFIRE-2040
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2040
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: David M. Karr
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> My organization is in the process of moving their SpringBoot Maven builds
> from JUnit 4 to JUnit 5. Our "default" build runs all the unit tests. We
> also have "component tests" and "integration tests" that are specified in a
> "TestSuite" class. The build process specifies the name of the suite class
> on the command line with "-Dtest=ComponentTestSuite", for instance. Before
> the move to JUnit 5, this all worked fine.
> In the move to JUnit 5, I modified ComponentTestSuite to be like this:
> import org.junit.platform.suite.api.SelectClasses;
> import org.junit.platform.suite.api.Suite;
> @Suite
> @SelectClasses(NoteResourceCT.class)
> public class ComponentTestSuite {
> }
> Now, when I run "mvn -Dtest=ComponentTestSuite test", it says the following:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project ...: No tests were executed! (Set -DfailIfNoTests=false to ignore
> this error.) -> [Help 1]
> There are no other messages.
> My pom.xml basically looks like this:
>
> ...
>
>
>
> org.junit
> junit-bom
> 5.8.2
> pom
> import
>
>
>
>
>
> org.springframework.boot
> spring-boot-starter-test
> test
>
>
> org.mockito
> mockito-junit-jupiter
> 4.4.0
> test
>
>
> junit
> junit
> 4.13.2
> test
>
>
> org.junit.platform
> junit-platform-suite-api
>
> ...
>
>
>
> ...
>
> maven-surefire-plugin
> 3.0.0-M5
>
> false
>
> true
>
>
> ...
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2040) No tests executed with junit-platform-suite and -Dtest=TestSuite
[
https://issues.apache.org/jira/browse/SUREFIRE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509535#comment-17509535
]
Tibor Digana commented on SUREFIRE-2040:
It is not truth that the problem comes from combining JUnit4 and JUnit5.
We have a project which proves that it is not a problem.
https://github.com/Tibor17/junit5-mockito-examples
The only problem is with -Dtest=ComponentTestSuite and this results to 0 tests
to run if and only if you use {{junit-platform-suite}}.
> No tests executed with junit-platform-suite and -Dtest=TestSuite
>
>
> Key: SUREFIRE-2040
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2040
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: David M. Karr
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> My organization is in the process of moving their SpringBoot Maven builds
> from JUnit 4 to JUnit 5. Our "default" build runs all the unit tests. We
> also have "component tests" and "integration tests" that are specified in a
> "TestSuite" class. The build process specifies the name of the suite class
> on the command line with "-Dtest=ComponentTestSuite", for instance. Before
> the move to JUnit 5, this all worked fine.
> In the move to JUnit 5, I modified ComponentTestSuite to be like this:
> import org.junit.platform.suite.api.SelectClasses;
> import org.junit.platform.suite.api.Suite;
> @Suite
> @SelectClasses(NoteResourceCT.class)
> public class ComponentTestSuite {
> }
> Now, when I run "mvn -Dtest=ComponentTestSuite test", it says the following:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project ...: No tests were executed! (Set -DfailIfNoTests=false to ignore
> this error.) -> [Help 1]
> There are no other messages.
> My pom.xml basically looks like this:
>
> ...
>
>
>
> org.junit
> junit-bom
> 5.8.2
> pom
> import
>
>
>
>
>
> org.springframework.boot
> spring-boot-starter-test
> test
>
>
> org.mockito
> mockito-junit-jupiter
> 4.4.0
> test
>
>
> junit
> junit
> 4.13.2
> test
>
>
> org.junit.platform
> junit-platform-suite-api
>
> ...
>
>
>
> ...
>
> maven-surefire-plugin
> 3.0.0-M5
>
> false
>
> true
>
>
> ...
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #492: Tests runorder
Tibor17 commented on a change in pull request #492: URL: https://github.com/apache/maven-surefire/pull/492#discussion_r830680663 ## File path: surefire-providers/surefire-junit4/src/main/java/org/apache/maven/surefire/junit4/JUnit4Provider.java ## @@ -270,18 +276,57 @@ private void executeTestSet( Class clazz, RunListener reporter, Notifier noti } } +private static int indexOf( List tests, Description description ) Review comment: If you do something like this, you are on wrong way. The problem is that you wanted to get to the end within one day, and that's the problem. You should follow those 5 steps, you would not get to the end after you have implemented first 4 steps but would would do 85% of your work without removing anything. If you are not sure in the beginning, it still right way to write an integration test because it is always needed and it is the vision you want to emphase to everyone. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #492: Tests runorder
Tibor17 commented on a change in pull request #492: URL: https://github.com/apache/maven-surefire/pull/492#discussion_r830680663 ## File path: surefire-providers/surefire-junit4/src/main/java/org/apache/maven/surefire/junit4/JUnit4Provider.java ## @@ -270,18 +276,57 @@ private void executeTestSet( Class clazz, RunListener reporter, Notifier noti } } +private static int indexOf( List tests, Description description ) Review comment: If you do something like this, you are on wrong way. The problem is that you wanted to get to the end within one day, and that's the problem. You should follow those 5 steps, you would not get to the end after you have implemented first 4 steps but would would do 85% of your work without removing anything. If you are not sure in the beginning, it is still right way to write an integration test because it is always needed and it is the vision you want to emphase to everyone. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #493: [SUREFIRE-2039] Fix skipped test classes reporting
Tibor17 commented on pull request #493: URL: https://github.com/apache/maven-surefire/pull/493#issuecomment-1073361298 @SammyVimes We fixed some issue regarding skipped tests in SUREFIRE-1556 but I am not sure it is the same. Sorry, but I do not trust this JIRA report because i do not know what test framework you use, how you "skip" the test and I am not able to reproduce this problem upon the JIRA description. How can I prove that this is a general problem and not individual problem and then why should I accept a fix which is not the right one. If we accepted all patches like this without a deep understanding and debugging the problem, we may have a serious problem which is a bigger than the reported one in the JIRA. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #493: [SUREFIRE-2039] Fix skipped test classes reporting
Tibor17 edited a comment on pull request #493: URL: https://github.com/apache/maven-surefire/pull/493#issuecomment-1073361298 @SammyVimes We fixed some issue regarding skipped tests in SUREFIRE-1556 but I am not sure it is the same. Sorry, but I do not trust this JIRA report because i do not know what test framework you use, how you "skip" the test and I am not able to reproduce this problem upon the JIRA description. How can I prove that this is a general problem and not individual problem and then why should I accept a fix which is not the right one. If we accepted all patches like this without a deep understanding and debugging the problem, we would have a serious problem which would be bigger than the reported one in JIRA. So sometimes, it is better to make a small step and precisely write JIRA ticket. Of course if you have debugged the code and helped us with the findings around the root cause, it would help and maybe we would make the fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 opened a new pull request #494: [SUREFIRE-2040] No tests executed with junit-platform-suite and -Dtest=TestSuite
Tibor17 opened a new pull request #494: URL: https://github.com/apache/maven-surefire/pull/494 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] davidmichaelkarr commented on a change in pull request #494: [SUREFIRE-2040] No tests executed with junit-platform-suite and -Dtest=TestSuite
davidmichaelkarr commented on a change in pull request #494:
URL: https://github.com/apache/maven-surefire/pull/494#discussion_r830762482
##
File path: surefire-its/src/test/resources/junit5-suite/pom.xml
##
@@ -0,0 +1,78 @@
+
+
+
+http://maven.apache.org/POM/4.0.0";
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
+ 4.0.0
+
+ org.example
+ junit5-suite
+ 1.0-SNAPSHOT
+
+
+UTF-8
+
${java.specification.version}
+
${java.specification.version}
+
+
+
+
+ org.junit.jupiter
+ junit-jupiter-api
+ 5.8.0
Review comment:
This is curious. The main dependencies are specifying v5.8.0 and v1.8.0,
but the Surefire plugin dependencies are specifying v5.8.2 and v1.8.2. Is that
difference intentional?
--
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
