[jira] [Created] (MNG-6720) MultiThreadedBuilder does not wait for outstanding projects to complete
Stefan Oehme created MNG-6720: - Summary: MultiThreadedBuilder does not wait for outstanding projects to complete Key: MNG-6720 URL: https://issues.apache.org/jira/browse/MNG-6720 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.1, 3.5.4 Reporter: Stefan Oehme When a project fails using --fail-fast mode, other projects that are currently running in parallel are not finished before the "session finished" event is sent. This leads to issues for extensions that rely on the documented order of events, which says that "session finished" is only sent "after all projects have finished executing". In our case, we close a service on "session finished", and that service is needed to execute goals. The goals that were running in parallel at that time then fail, saying that our service was closed, giving our users the impression that there is a bug in our code. The relevant line is [here|[https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]]. Instead of using `poll`, which simply returns when the parallel projects aren't finished yet, the code should shut down the executor and wait for it to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MNG-6720) MultiThreadedBuilder does not wait for outstanding projects to complete
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-6720: -- Description: When a project fails using --fail-fast mode, other projects that are currently running in parallel are not finished before the "session finished" event is sent. This leads to issues for extensions that rely on the documented order of events, which says that "session finished" is only sent "after all projects have been finished/skipped". In our case, we close a service on "session finished", and that service is needed to execute goals. The goals that were running in parallel at that time then fail, saying that our service was closed, giving our users the impression that there is a bug in our code. The relevant line is [here|[https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]]. Instead of using `poll`, which simply returns when the parallel projects aren't finished yet, the code should shut down the executor and wait for it to complete the outstanding parallel work. was: When a project fails using --fail-fast mode, other projects that are currently running in parallel are not finished before the "session finished" event is sent. This leads to issues for extensions that rely on the documented order of events, which says that "session finished" is only sent "after all projects have finished executing". In our case, we close a service on "session finished", and that service is needed to execute goals. The goals that were running in parallel at that time then fail, saying that our service was closed, giving our users the impression that there is a bug in our code. The relevant line is [here|[https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]]. Instead of using `poll`, which simply returns when the parallel projects aren't finished yet, the code should shut down the executor and wait for it to complete the outstanding parallel work. > MultiThreadedBuilder does not wait for outstanding projects to complete > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Priority: Major > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|[https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MNG-6720) MultiThreadedBuilder does not wait for outstanding projects to complete
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-6720: -- Description: When a project fails using --fail-fast mode, other projects that are currently running in parallel are not finished before the "session finished" event is sent. This leads to issues for extensions that rely on the documented order of events, which says that "session finished" is only sent "after all projects have been finished/skipped". In our case, we close a service on "session finished", and that service is needed to execute goals. The goals that were running in parallel at that time then fail, saying that our service was closed, giving our users the impression that there is a bug in our code. The relevant line is [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. Instead of using `poll`, which simply returns when the parallel projects aren't finished yet, the code should shut down the executor and wait for it to complete the outstanding parallel work. was: When a project fails using --fail-fast mode, other projects that are currently running in parallel are not finished before the "session finished" event is sent. This leads to issues for extensions that rely on the documented order of events, which says that "session finished" is only sent "after all projects have been finished/skipped". In our case, we close a service on "session finished", and that service is needed to execute goals. The goals that were running in parallel at that time then fail, saying that our service was closed, giving our users the impression that there is a bug in our code. The relevant line is [here|[https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]]. Instead of using `poll`, which simply returns when the parallel projects aren't finished yet, the code should shut down the executor and wait for it to complete the outstanding parallel work. > MultiThreadedBuilder does not wait for outstanding projects to complete > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Priority: Major > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder does not wait for outstanding projects to complete
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892469#comment-16892469 ] Stefan Oehme commented on MNG-6720: --- It should fail fast, but not at the expense of correctness. As described above, Maven notifies us that the build has finished, but it's actually still executing things, which breaks the contract of these events. It's a totally uncoordinated shutdown, which I don't think is a good user experience. We could try to make it wrap up faster, e.g. by calling `shutDownNow`, which will interrupt the execution threads. There's no hard guarantee that all Mojos support interrupts, but in general it should fail faster with that. Sounds good? As for testing, it's actually pretty hard to reproduce with a small project, since it's a race condition between the goal failing and the VM shutting down. I may have to create a pretty large number of projects to make the test consistently fail. I'll see if that still gives a reasonable test execution time. > MultiThreadedBuilder does not wait for outstanding projects to complete > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894154#comment-16894154 ] Stefan Oehme commented on MNG-6720: --- Correct, my current solution waits for the concurrently running modules, but doesn't let any new ones start and then cleanly shuts down the build. > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894380#comment-16894380 ] Stefan Oehme commented on MNG-6720: --- > I would expect that the poll() is still required to empty the waiting > projectSegments. poll() doesn't wait, see its javadoc. It just returns null immediately if there is no finished project available. > I don't see any fork/join related code, but maybe I'm missing a detail. We wait for the executor to finish, which will wait for all scheduled work. Yes, I can add a test. > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[
https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895335#comment-16895335
]
Stefan Oehme commented on MNG-6720:
---
I have a test case ready, but after pulling in the latest master branch of the
core-it project, everything is failing, even the "bootstrap" test, without any
changes on my side. The first error message is:
{code:java}
Failure to find
org.apache.maven.plugins:maven-clean-plugin:jar:0.1-stub-SNAPSHOT in
http://repo1.maven.org/maven2 was cached in the local repository, resolution
will not be reattempted until the update interval of central has elapsed or
updates are forced
{code}
> MultiThreadedBuilder: wait for parallel running projects when using
> --fail-fast
> ---
>
> Key: MNG-6720
> URL: https://issues.apache.org/jira/browse/MNG-6720
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.4, 3.6.1
>Reporter: Stefan Oehme
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.x-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a project fails using --fail-fast mode, other projects that are
> currently running in parallel are not finished before the "session finished"
> event is sent. This leads to issues for extensions that rely on the
> documented order of events, which says that "session finished" is only sent
> "after all projects have been finished/skipped".
> In our case, we close a service on "session finished", and that service is
> needed to execute goals. The goals that were running in parallel at that time
> then fail, saying that our service was closed, giving our users the
> impression that there is a bug in our code.
> The relevant line is
> [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179].
> Instead of using `poll`, which simply returns when the parallel projects
> aren't finished yet, the code should shut down the executor and wait for it
> to complete the outstanding parallel work.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895340#comment-16895340 ] Stefan Oehme commented on MNG-6720: --- Ah nevermind, it seems that the `-Dmaven.repo.local` argument does not tolerate relative paths. > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895356#comment-16895356 ] Stefan Oehme commented on MNG-6720: --- Test is here: https://github.com/apache/maven-integration-testing/pull/45 > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895356#comment-16895356 ] Stefan Oehme edited comment on MNG-6720 at 7/29/19 3:25 PM: Test is here: https://github.com/apache/maven-integration-testing/pull/45. It fails on master and succeeds with my changes. was (Author: oehme): Test is here: https://github.com/apache/maven-integration-testing/pull/45 > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
Stefan Oehme created SUREFIRE-1655: -- Summary: Surefire leaks classloaders when using in-process strategy Key: SUREFIRE-1655 URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Stefan Oehme The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
[ https://issues.apache.org/jira/browse/SUREFIRE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1655: --- Description: The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. was: The test classloader is created [here| [https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. > Surefire leaks classloaders when using in-process strategy > -- > > Key: SUREFIRE-1655 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The test classloader is created > [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], > but never closed. As a result, the underlying JARs in that classloader > remain open and cannot be deleted. Also, their content can be stale when > opened using java.util.ZipFile. > This is a problem when running Maven integration tests using the > Embedded3xLauncher. We are developing a Maven extension and want to make sure > it works well with surefire/failsafe. This classloader leak means we have to > use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
[ https://issues.apache.org/jira/browse/SUREFIRE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1655: --- Description: The test classloader is created [here| [https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. was: The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. > Surefire leaks classloaders when using in-process strategy > -- > > Key: SUREFIRE-1655 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The test classloader is created [here| > [https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], > but never closed. As a result, the underlying JARs in that classloader > remain open and cannot be deleted. Also, their content can be stale when > opened using java.util.ZipFile. > This is a problem when running Maven integration tests using the > Embedded3xLauncher. We are developing a Maven extension and want to make sure > it works well with surefire/failsafe. This classloader leak means we have to > use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
[ https://issues.apache.org/jira/browse/SUREFIRE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1655: --- Description: The test classloader is created [here|https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. was: The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. > Surefire leaks classloaders when using in-process strategy > -- > > Key: SUREFIRE-1655 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The test classloader is created > [here|https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77], > but never closed. As a result, the underlying JARs in that classloader > remain open and cannot be deleted. Also, their content can be stale when > opened using java.util.ZipFile. > This is a problem when running Maven integration tests using the > Embedded3xLauncher. We are developing a Maven extension and want to make sure > it works well with surefire/failsafe. This classloader leak means we have to > use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6619) Core extensions should not be in plexus.core classloader
Stefan Oehme created MNG-6619: - Summary: Core extensions should not be in plexus.core classloader Key: MNG-6619 URL: https://issues.apache.org/jira/browse/MNG-6619 Project: Maven Issue Type: Bug Components: core Reporter: Stefan Oehme The core extensions classloader is set up in [MavenCli|https://github.com/apache/maven/blob/b7249aff22b8993ddecfed26003c2e1bc04e708c/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L788]. However, [this line|https://github.com/apache/maven/blob/0be26449fb96774be126a6ad245d1a98dc71907c/apache-maven/src/bin/m2.conf#L7] also loads them into the plexus.core classloader, which is really just supposed to contain the Maven core jars. This can lead to problems when event spies are added to `lib/ext`. They are instantiated and get events when resolving other extensions during the `loadCoreExtensions` method, even though they have not yet been initialized. I assume that the line in m2.conf is just outdated and superseded by `loadCoreExtensions` and should thus be removed to avoid non-initialized event spies being called while loading extensions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6629) DefaultModelValidator.validateId is inefficient
Stefan Oehme created MNG-6629: - Summary: DefaultModelValidator.validateId is inefficient Key: MNG-6629 URL: https://issues.apache.org/jira/browse/MNG-6629 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0 Reporter: Stefan Oehme I'm currently optimizing a very large (2000+ submodule) project. DefaultModelValidator.validateId is one of the CPU hotspots, as it uses a regex for validating every ID in the model. Iterating over the characters and checking them against valid ranges would be faster and less memory intensive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6629) DefaultModelValidator.validateId is inefficient
[ https://issues.apache.org/jira/browse/MNG-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815231#comment-16815231 ] Stefan Oehme commented on MNG-6629: --- See [https://github.com/apache/maven/pull/242] > DefaultModelValidator.validateId is inefficient > --- > > Key: MNG-6629 > URL: https://issues.apache.org/jira/browse/MNG-6629 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Stefan Oehme >Priority: Major > > > I'm currently optimizing a very large (2000+ submodule) project. > DefaultModelValidator.validateId is one of the CPU hotspots, as it uses a > regex for validating every ID in the model. Iterating over the characters and > checking them against valid ranges would be faster and less memory intensive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6630) ComparableVersion.parseVersion is inefficient
Stefan Oehme created MNG-6630: - Summary: ComparableVersion.parseVersion is inefficient Key: MNG-6630 URL: https://issues.apache.org/jira/browse/MNG-6630 Project: Maven Issue Type: Bug Reporter: Stefan Oehme I'm currently optimizing a very large (2000+ submodule) project. ComparableVersion.parseVersion is one of the CPU/memory hotspots, because it creates a "canonical" String from the parsed parts, even though that String is only used by tests/debugging. It would be more efficient to only create that String on demand. See [https://github.com/apache/maven/pull/242] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6631) DefaultArtifactVersion.parseVersion is inefficient
Stefan Oehme created MNG-6631: - Summary: DefaultArtifactVersion.parseVersion is inefficient Key: MNG-6631 URL: https://issues.apache.org/jira/browse/MNG-6631 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0 Reporter: Stefan Oehme I'm currently optimizing a very large (2000+ submodule) project. DefaultArtifactVersion.parseVersion is one of the CPU/memory hotspots, because it uses exceptions for control flow. Using if-statements instead would be much faster. See [https://github.com/apache/maven/pull/242] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6632) ArtifactHandlerManager.getArtifactHandler is inefficient
Stefan Oehme created MNG-6632: - Summary: ArtifactHandlerManager.getArtifactHandler is inefficient Key: MNG-6632 URL: https://issues.apache.org/jira/browse/MNG-6632 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0 Reporter: Stefan Oehme I'm currently optimizing a very large (2000+ submodule) project. ArtifactHandlerManager.getArtifactHandler is one of the CPU/memory hotspots, because for every `get` call it goes through the Map injected by Plexus. This Map has O(n) lookup performance, because it is backed by an `Iterable`. It would be much faster to remember the artifact handlers that have already been found. See [https://github.com/apache/maven/pull/242] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6630) ComparableVersion.parseVersion is inefficient
[ https://issues.apache.org/jira/browse/MNG-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-6630: -- Affects Version/s: 3.6.0 Component/s: core > ComparableVersion.parseVersion is inefficient > - > > Key: MNG-6630 > URL: https://issues.apache.org/jira/browse/MNG-6630 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Stefan Oehme >Priority: Major > > I'm currently optimizing a very large (2000+ submodule) project. > ComparableVersion.parseVersion is one of the CPU/memory hotspots, because it > creates a "canonical" String from the parsed parts, even though that String > is only used by tests/debugging. It would be more efficient to only create > that String on demand. > See [https://github.com/apache/maven/pull/242] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6632) ArtifactHandlerManager.getArtifactHandler is inefficient
[ https://issues.apache.org/jira/browse/MNG-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-6632: -- Description: I'm currently optimizing a very large (2000+ submodule) project. ArtifactHandlerManager.getArtifactHandler is one of the CPU/memory hotspots, because for every `get` call it goes through the Map injected by Plexus. This Map has O( n ) lookup performance, because it is backed by an `Iterable`. It would be much faster to remember the artifact handlers that have already been found. See [https://github.com/apache/maven/pull/242] was: I'm currently optimizing a very large (2000+ submodule) project. ArtifactHandlerManager.getArtifactHandler is one of the CPU/memory hotspots, because for every `get` call it goes through the Map injected by Plexus. This Map has O(n) lookup performance, because it is backed by an `Iterable`. It would be much faster to remember the artifact handlers that have already been found. See [https://github.com/apache/maven/pull/242] > ArtifactHandlerManager.getArtifactHandler is inefficient > > > Key: MNG-6632 > URL: https://issues.apache.org/jira/browse/MNG-6632 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Stefan Oehme >Priority: Major > > I'm currently optimizing a very large (2000+ submodule) project. > ArtifactHandlerManager.getArtifactHandler is one of the CPU/memory hotspots, > because for every `get` call it goes through the Map injected by Plexus. This > Map has O( n ) lookup performance, because it is backed by an `Iterable`. It > would be much faster to remember the artifact handlers that have already been > found. > See [https://github.com/apache/maven/pull/242] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6633) ExcludesArtifactFilter is a memory hog
Stefan Oehme created MNG-6633: - Summary: ExcludesArtifactFilter is a memory hog Key: MNG-6633 URL: https://issues.apache.org/jira/browse/MNG-6633 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0 Reporter: Stefan Oehme It takes the group and artifact ID of an Exclusion, concatenates them into a new String, which is kept in memory for the whole duration of the build and then compares that String against the concatenation of group and artifact ID of each incoming artifact, adding more CPU cycles than necessary. Instead it should just take the group and artifact ID from the Exclusion object and compare them against the group and artifact ID of the Artifact. For the 2000 module build I'm currently profiling, this is wasting over 1GB of RAM, with hundreds of thousands of duplicated Strings. Pull request following shortly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6633) ExcludesArtifactFilter is a memory hog
[ https://issues.apache.org/jira/browse/MNG-6633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-6633: -- Description: It takes the group and artifact ID of an Exclusion, concatenates them into a new String, which is kept in memory for the whole duration of the build and then compares that String against the concatenation of group and artifact ID of each incoming artifact, adding more CPU cycles than necessary. Instead it should just take the group and artifact ID from the Exclusion object and compare them against the group and artifact ID of the Artifact. For the 2000 module build I'm currently profiling, this is wasting over 1GB of RAM, with hundreds of thousands of duplicated Strings. See [https://github.com/apache/maven/pull/243] was: It takes the group and artifact ID of an Exclusion, concatenates them into a new String, which is kept in memory for the whole duration of the build and then compares that String against the concatenation of group and artifact ID of each incoming artifact, adding more CPU cycles than necessary. Instead it should just take the group and artifact ID from the Exclusion object and compare them against the group and artifact ID of the Artifact. For the 2000 module build I'm currently profiling, this is wasting over 1GB of RAM, with hundreds of thousands of duplicated Strings. Pull request following shortly > ExcludesArtifactFilter is a memory hog > -- > > Key: MNG-6633 > URL: https://issues.apache.org/jira/browse/MNG-6633 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Stefan Oehme >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It takes the group and artifact ID of an Exclusion, concatenates them into a > new String, which is kept in memory for the whole duration of the build and > then compares that String against the concatenation of group and artifact ID > of each incoming artifact, adding more CPU cycles than necessary. Instead it > should just take the group and artifact ID from the Exclusion object and > compare them against the group and artifact ID of the Artifact. > > For the 2000 module build I'm currently profiling, this is wasting over 1GB > of RAM, with hundreds of thousands of duplicated Strings. > > See [https://github.com/apache/maven/pull/243] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6638) MavenMetadataSource parses POMs unnecessarily
Stefan Oehme created MNG-6638: - Summary: MavenMetadataSource parses POMs unnecessarily Key: MNG-6638 URL: https://issues.apache.org/jira/browse/MNG-6638 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.1, 3.6.0, 3.5.4 Reporter: Stefan Oehme MavenMetadataSource parses POM files even when an artifact comes from a project that is part of the current reactor build. This wastes a lot of time and memory, since the POMs of these projects are already in memory. It should instead try to find an existing project model in the reactor before falling back to POM parsing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6668) Model location handling uses too much memory
Stefan Oehme created MNG-6668: - Summary: Model location handling uses too much memory Key: MNG-6668 URL: https://issues.apache.org/jira/browse/MNG-6668 Project: Maven Issue Type: Bug Components: core Reporter: Stefan Oehme Every model element in Maven has one or several Location objects associated with it. These locations specify where in the POM each attribute of that object was configured. This is a very useful feature for better error messages and IDE assistance, but its current implementation takes too much memory. Locations are currently tracked with a LinkedHashMap, with String keys and Location values. LinkedHashMap has a large overhead per entry. In a particularly large build that I was investigating, just this overhead summed up to almost 3GB of memory. However, there is actually no need for arbitrary Strings or a Map. The keys are always the name of the corresponding field in the model class. So instead we could create one Location field for every actual data field in the model and then switch over the String key to assign the Location to the correct field. This would get rid of the LinkedHashMap overhead altogether. It would add a small overhead for modello users who don't care about location handling, but I assume that Maven is the only major consumer of it. See [https://github.com/codehaus-plexus/modello/pull/31] and [https://github.com/apache/maven/pull/252] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-7131) maven.config doesn't handle arguments with spaces in them
[
https://issues.apache.org/jira/browse/MNG-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381209#comment-17381209
]
Stefan Oehme commented on MNG-7131:
---
Sorry for not getting back to you on this. This is not an important issue for
me, I just stumbled upon it while exploring Maven's behavior and thought I'd
report it. I won't have time to work on this. The description has all the info
that anyone who wants to work on this will need though.
> maven.config doesn't handle arguments with spaces in them
> -
>
> Key: MNG-7131
> URL: https://issues.apache.org/jira/browse/MNG-7131
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Stefan Oehme
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> I tried putting a path with a space in the maven.config like so:
> {code:java}
> "-Dmy.path=/some/path with/a/space"
> {code}
> When asking for the my.path property inside Maven, I get the path with a
> trailing quote
> {code:java}
> /some/path with/a/space"
> {code}
> The file is parsed by [splitting it by
> whitespace|https://github.com/apache/maven/blob/c3cf29438e3d65d6ee5c5726f8611af99d9a649a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L386].
> I suggest replacing that code with the much better
> [CommandLineUtils.translateCommandline(argLine)|https://github.com/codehaus-plexus/plexus-utils/blob/85a4a3c534752919dd97d757d4ef0fdb6d40eb8c/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L412]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7131) maven.config doesn't handle arguments with spaces in them
[
https://issues.apache.org/jira/browse/MNG-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386682#comment-17386682
]
Stefan Oehme commented on MNG-7131:
---
Lgtm
> maven.config doesn't handle arguments with spaces in them
> -
>
> Key: MNG-7131
> URL: https://issues.apache.org/jira/browse/MNG-7131
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Stefan Oehme
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> I tried putting a path with a space in the maven.config like so:
> {code:java}
> "-Dmy.path=/some/path with/a/space"
> {code}
> When asking for the my.path property inside Maven, I get the path with a
> trailing quote
> {code:java}
> /some/path with/a/space"
> {code}
> The file is parsed by [splitting it by
> whitespace|https://github.com/apache/maven/blob/c3cf29438e3d65d6ee5c5726f8611af99d9a649a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L386].
> I suggest replacing that code with the much better
> [CommandLineUtils.translateCommandline(argLine)|https://github.com/codehaus-plexus/plexus-utils/blob/85a4a3c534752919dd97d757d4ef0fdb6d40eb8c/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L412]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1878) Add failOnFlake option
Stefan Oehme created SUREFIRE-1878: -- Summary: Add failOnFlake option Key: SUREFIRE-1878 URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Reporter: Stefan Oehme The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail on failed tests, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1878: --- Description: The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. was: The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail on failed tests, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268188#comment-17268188 ] Stefan Oehme commented on SUREFIRE-1878: Or maybe even better `skipAfterFlakeCount` to match `skipAfterFailureCount`. > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268188#comment-17268188 ] Stefan Oehme edited comment on SUREFIRE-1878 at 1/22/21, 11:58 AM: --- Or maybe even better `failAfterFlakeCount` to match `skipAfterFailureCount`. was (Author: oehme): Or maybe even better `skipAfterFlakeCount` to match `skipAfterFailureCount`. > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273525#comment-17273525 ] Stefan Oehme commented on SUREFIRE-1878: I've created a draft PR to clarify what I have in mind: https://github.com/apache/maven-surefire/pull/333 > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1878: --- Description: The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. Edit: To clarify, this is about failing the whole test set when there is flakiness, not individual tests. was: The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. > Edit: To clarify, this is about failing the whole test set when there is > flakiness, not individual tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1902) Non-modules are put on the module path when test sources contain a module-info file
Stefan Oehme created SUREFIRE-1902: -- Summary: Non-modules are put on the module path when test sources contain a module-info file Key: SUREFIRE-1902 URL: https://issues.apache.org/jira/browse/SUREFIRE-1902 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 3.0.0-M5 Reporter: Stefan Oehme When the test sources contain a module-info file, Surefire currently [puts everything on the module path|https://github.com/apache/maven-surefire/blob/b9b2381a3dba6574bb69bd91d45fe0edea29c779/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2057], even dependencies that are not modules. When the main sources contain a module-info file, it [uses Plexus-Java|https://github.com/apache/maven-surefire/blob/b9b2381a3dba6574bb69bd91d45fe0edea29c779/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2034] to determine what to put on the module path and what to put on the classpath. I'm not sure what kind of use cases this will break, but it seems inconsistent to me. Shouldn't Plexus-Java be used in both cases? Marking as a minor issue since I'm not blocked by this, I was just curious why this was done differently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7131) maven.config doesn't handle arguments with spaces in them
Stefan Oehme created MNG-7131:
-
Summary: maven.config doesn't handle arguments with spaces in them
Key: MNG-7131
URL: https://issues.apache.org/jira/browse/MNG-7131
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.6.3
Reporter: Stefan Oehme
I tried putting a path with a space in the maven.config like so:
{code:java}
"-Dmy.path=/some/path with/a/space"
{code}
When asking for the my.path property inside Maven, I get the path with a
trailing quote
{code:java}
/some/path with/a/space"
{code}
The file is parsed by [splitting it by
whitespace|https://github.com/apache/maven/blob/c3cf29438e3d65d6ee5c5726f8611af99d9a649a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L386].
I suggest replacing that code with the much better
[CommandLineUtils.translateCommandline(argLine)|https://github.com/codehaus-plexus/plexus-utils/blob/85a4a3c534752919dd97d757d4ef0fdb6d40eb8c/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L412]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7131) maven.config doesn't handle arguments with spaces in them
[
https://issues.apache.org/jira/browse/MNG-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Oehme updated MNG-7131:
--
Priority: Minor (was: Major)
> maven.config doesn't handle arguments with spaces in them
> -
>
> Key: MNG-7131
> URL: https://issues.apache.org/jira/browse/MNG-7131
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Stefan Oehme
>Priority: Minor
>
> I tried putting a path with a space in the maven.config like so:
> {code:java}
> "-Dmy.path=/some/path with/a/space"
> {code}
> When asking for the my.path property inside Maven, I get the path with a
> trailing quote
> {code:java}
> /some/path with/a/space"
> {code}
> The file is parsed by [splitting it by
> whitespace|https://github.com/apache/maven/blob/c3cf29438e3d65d6ee5c5726f8611af99d9a649a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L386].
> I suggest replacing that code with the much better
> [CommandLineUtils.translateCommandline(argLine)|https://github.com/codehaus-plexus/plexus-utils/blob/85a4a3c534752919dd97d757d4ef0fdb6d40eb8c/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L412]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-8299) Maven 4 reverses custom lifecycle ordering
Stefan Oehme created MNG-8299:
-
Summary: Maven 4 reverses custom lifecycle ordering
Key: MNG-8299
URL: https://issues.apache.org/jira/browse/MNG-8299
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.x-candidate
Reporter: Stefan Oehme
Following this tutorial:
[https://nextmetaphor.wordpress.com/2016/10/10/custom-maven-lifecycle/]
On Maven 3.x, if you run `mvn phase3` on the project, it correctly runs phase 1
and 2 first and outputs
{code:java}
[INFO] Doing Phase 1 stuff. {code}
On the 4.x nightlies, running the same command no longer runs phase 1 or 2. It
looks like the order of phases is reversed. This happened after
[https://github.com/apache/maven/pull/1448] was merged I think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8297) Color output no longer possible on dumb terminals
Stefan Oehme created MNG-8297: - Summary: Color output no longer possible on dumb terminals Key: MNG-8297 URL: https://issues.apache.org/jira/browse/MNG-8297 Project: Maven Issue Type: Bug Components: Logging Affects Versions: 4.0.x-candidate Reporter: Stefan Oehme We have a couple of integration tests for how our tool captures Maven console output, including color. These tests capture Maven's output in a ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we still get color output. With the latest 4.x nightlies, the output is no longer colored. I dug through the code a bit and it seems to be related to the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, but that didn't bring coloring back. You can try this yourself by doing `export TERM=dumb`, followed by any Maven command. The output is uncolored, even though Maven itself says `Message scheme: color` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8297) Color output no longer possible on dumb terminals
[ https://issues.apache.org/jira/browse/MNG-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-8297: -- Description: We have a couple of integration tests for how our tool captures Maven console output, including color. These tests capture Maven's output in a ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we still get color output. With the latest 4.x nightlies, the output is no longer colored. I dug through the code a bit and it seems to be related to the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, but that didn't bring coloring back. You can try this yourself by doing `export TERM=dumb`, followed by any Maven command. The output is uncolored, even though Maven itself says `Message scheme: color` To be clear, I think having no color on dumb terminals is the correct default, but there should be a switch to bring it back for testing purposes. If there already is, please let me know how. was: We have a couple of integration tests for how our tool captures Maven console output, including color. These tests capture Maven's output in a ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we still get color output. With the latest 4.x nightlies, the output is no longer colored. I dug through the code a bit and it seems to be related to the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, but that didn't bring coloring back. You can try this yourself by doing `export TERM=dumb`, followed by any Maven command. The output is uncolored, even though Maven itself says `Message scheme: color` > Color output no longer possible on dumb terminals > - > > Key: MNG-8297 > URL: https://issues.apache.org/jira/browse/MNG-8297 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 4.0.x-candidate >Reporter: Stefan Oehme >Priority: Major > > We have a couple of integration tests for how our tool captures Maven console > output, including color. These tests capture Maven's output in a > ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we > still get color output. With the latest 4.x nightlies, the output is no > longer colored. I dug through the code a bit and it seems to be related to > the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, > but that didn't bring coloring back. > You can try this yourself by doing `export TERM=dumb`, followed by any Maven > command. The output is uncolored, even though Maven itself says `Message > scheme: color` > To be clear, I think having no color on dumb terminals is the correct > default, but there should be a switch to bring it back for testing purposes. > If there already is, please let me know how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8298) 4.x nightly breaks maven-resources plugin (and possibly others)
Stefan Oehme created MNG-8298:
-
Summary: 4.x nightly breaks maven-resources plugin (and possibly
others)
Key: MNG-8298
URL: https://issues.apache.org/jira/browse/MNG-8298
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.x-candidate
Reporter: Stefan Oehme
The latest Maven 4.x nightlies no longer work with the latest nightlies of core
Maven plugins like the maven-resources plugin. It looks like this was caused by
this classloading change: [https://github.com/apache/maven/pull/1336]
Example stacktrace when using the latest maven-resources-plugin:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources
(default-resources) on project a: Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources
failed: Unable to lookup Mojo: Error while initializing binding
BindingToConstructor[@Named("org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources")
ResourcesMojoFactory][]: Error while initializing binding
BindingToConstructor[@Named
DefaultMavenResourcesFiltering][Dependency[key=BuildContext, optional=false],
Dependency[key=MavenFileFilter, optional=false]]: Error while initializing
binding BindingToConstructor[@Named
DefaultMavenFileFilter][Dependency[key=BuildContext, optional=false]]: Failed
to call method static org.sonatype.plexus.build.incremental.BuildContext
org.apache.maven.plugins.resources.Providers.buildContext():
org/codehaus/plexus/logging/AbstractLogEnabled:
org.codehaus.plexus.logging.AbstractLogEnabled -> [Help 1]
{code}
Is there a timeline for getting these plugins working again? We'd love to run
our tests against the latest of everything to make sure our Maven extension
works correctly when 4.0 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8297) Color output no longer possible on dumb terminals
[ https://issues.apache.org/jira/browse/MNG-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888665#comment-17888665 ] Stefan Oehme commented on MNG-8297: --- Yep, adding both system properties brings color back. It does feel a bit clunky though :) > Color output no longer possible on dumb terminals > - > > Key: MNG-8297 > URL: https://issues.apache.org/jira/browse/MNG-8297 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 4.0.x-candidate >Reporter: Stefan Oehme >Assignee: Guillaume Nodet >Priority: Major > > We have a couple of integration tests for how our tool captures Maven console > output, including color. These tests capture Maven's output in a > ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we > still get color output. With the latest 4.x nightlies, the output is no > longer colored. I dug through the code a bit and it seems to be related to > the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, > but that didn't bring coloring back. > You can try this yourself by doing `export TERM=dumb`, followed by any Maven > command. The output is uncolored, even though Maven itself says `Message > scheme: color` > To be clear, I think having no color on dumb terminals is the correct > default, but there should be a switch to bring it back for testing purposes. > If there already is, please let me know how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8305) CLIng does not populate MavenExecutionRequest.showErrors properly
Stefan Oehme created MNG-8305:
-
Summary: CLIng does not populate MavenExecutionRequest.showErrors
properly
Key: MNG-8305
URL: https://issues.apache.org/jira/browse/MNG-8305
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.x-candidate
Reporter: Stefan Oehme
The old Maven CLI uses
{code:java}
cliRequest.showErrors = cliRequest.verbose ||
commandLine.hasOption(CLIManager.ERRORS);{code}
The new CLIng uses
{code:java}
request.setShowErrors(options.showErrors().orElse(false)); {code}
Which doesn't take into account the verbose flag.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8530) Maven 4 prompter broken
[
https://issues.apache.org/jira/browse/MNG-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924101#comment-17924101
]
Stefan Oehme commented on MNG-8530:
---
Thank you Tamas, that looks a lot more comprehensive than what I had in mind :)
I'll test as soon as it's in the nightly.
> Maven 4 prompter broken
> ---
>
> Key: MNG-8530
> URL: https://issues.apache.org/jira/browse/MNG-8530
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> The [new
> prompter|https://github.com/apache/maven/blob/master/impl/maven-core/src/main/java/org/apache/maven/internal/impl/DefaultPrompter.java#L50]
> implementation reflectively calls the old one and always uses the same
> method no matter what overload was called:
> {code:java}
> clazz.getMethod("prompt", String.class, List.class, String.class); {code}
>
> This is incorrect and leads to nullpointers when calling the new prompter
> with just a `message`, but no `possibleValues`.
> The new prompter should delegate to the correct overload of the old prompter
> instead of redirecting all calls to the same method. Also, the nullability
> annnotations are wrong. The message is never nullable. And if an overload
> with `possibleValues` is called, they must not be null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-826) Aggregate mojo broken on Maven 4
Stefan Oehme created MJAVADOC-826:
-
Summary: Aggregate mojo broken on Maven 4
Key: MJAVADOC-826
URL: https://issues.apache.org/jira/browse/MJAVADOC-826
Project: Maven Javadoc Plugin
Issue Type: Bug
Reporter: Stefan Oehme
On Maven 4, the aggregate plugin fails with
{code:java}
Caused by: java.lang.UnsupportedOperationException
at java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
at
java.util.ImmutableCollections$AbstractImmutableCollection.addAll(ImmutableCollections.java:148)
at
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getSourcePaths(AbstractJavadocMojo.java:2207)
{code}
This is because it tries to modify the project's sourceRoots instead of making
a copy first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8535) Embedded launcher can't capture Maven 4 output
[
https://issues.apache.org/jira/browse/MNG-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923106#comment-17923106
]
Stefan Oehme commented on MNG-8535:
---
No, same issue still.
Looking at the JLine master branch, you haven't changed the problematic line:
https://github.com/jline/jline3/blob/de0a14ab81d613f5119c003f88a91f0ef192/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50
It still uses the underlying file streams directly.
> Embedded launcher can't capture Maven 4 output
> --
>
> Key: MNG-8535
> URL: https://issues.apache.org/jira/browse/MNG-8535
> Project: Maven
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> We have a lot of tests capturing and validating the output of Maven builds
> and use an embedded launcher by default to make our tests fast. With Maven 4
> and CliNG, our embedder can no longer capture Maven's output. At first I
> thought there was something wrong with our embedder, but I can reproduce this
> with the EmbeddedMavenExecutor provided by the Maven team as well:
>
> {code:java}
> public static void main(String[] args) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> new EmbeddedMavenExecutor(false).execute(ExecutorRequest
> .mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
> .cwd(Paths.get("/path/to/simple-project"))
> .argument("package")
> .stdoutConsumer(out)
> .build()
> );
> System.out.println("Output was: " + out);
> } {code}
> The above program should capture Maven's output, but actually the output is
> dumped directly to the console and the `out` variable remains empty.
>
> This puzzled me, because the embedded launcher [does replace System.out and
> System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
> so it looks like it should work. After some digging I found out that this is
> because of JLine. It doesn't use System.out or System.err, [but instead
> writes directly to the underlying filedescriptors
> |https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
> Please provide a way to capture Maven 4's output with the embedded launcher,
> like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8535) Embedded launcher can't capture Maven 4 output
Stefan Oehme created MNG-8535:
-
Summary: Embedded launcher can't capture Maven 4 output
Key: MNG-8535
URL: https://issues.apache.org/jira/browse/MNG-8535
Project: Maven
Issue Type: Bug
Components: Embedding
Affects Versions: 4.0.0-rc-3
Reporter: Stefan Oehme
We have a lot of tests capturing and validating the output of Maven builds and
use an embedded launcher by default to make our tests fast. With Maven 4 and
CliNG, our embedder can no longer capture Maven's output. At first I thought
there was something wrong with our embedder, but I can reproduce this with the
EmbeddedMavenExecutor provided by the Maven team as well:
{code:java}
public static void main(String[] args) {
ByteArrayOutputStream out = new ByteArrayOutputStream();
new EmbeddedMavenExecutor(false).execute(ExecutorRequest
.mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
.cwd(Paths.get("/path/to/simple-project"))
.argument("package")
.stdoutConsumer(out)
.build()
);
System.out.println("Output was: " + out);
} {code}
The above program should capture Maven's output, but actually the output is
dumped directly to the console and the `out` variable remains empty.
This puzzled me, because the embedded launcher [does replace System.out and
System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
so it looks like it should work. After some digging I found out that this is
because of JLine. It doesn't use System.out or System.err, [but instead writes
directly to the underlying filedescriptors
|https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
Please provide a way to capture Maven 4's output with the embedded launcher,
like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8530) Maven 4 prompter broken
Stefan Oehme created MNG-8530:
-
Summary: Maven 4 prompter broken
Key: MNG-8530
URL: https://issues.apache.org/jira/browse/MNG-8530
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-rc-2
Reporter: Stefan Oehme
The [new
prompter|https://github.com/apache/maven/blob/master/impl/maven-core/src/main/java/org/apache/maven/internal/impl/DefaultPrompter.java#L50]
implementation reflectively calls the old one and always uses the same method
no matter what overload was called:
{code:java}
clazz.getMethod("prompt", String.class, List.class, String.class); {code}
This is incorrect and leads to nullpointers when calling the new prompter with
just a `message`, but no `possibleValues`.
The new prompter should delegate to the correct overload of the old prompter
instead of redirecting all calls to the same method. Also, the nullability
annnotations are wrong. The message is never nullable. And if an overload with
`possibleValues` is called, they must not be null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8530) Maven 4 prompter broken
[
https://issues.apache.org/jira/browse/MNG-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Oehme updated MNG-8530:
--
Affects Version/s: 4.0.0-rc-3
(was: 4.0.0-rc-2)
> Maven 4 prompter broken
> ---
>
> Key: MNG-8530
> URL: https://issues.apache.org/jira/browse/MNG-8530
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Priority: Major
>
> The [new
> prompter|https://github.com/apache/maven/blob/master/impl/maven-core/src/main/java/org/apache/maven/internal/impl/DefaultPrompter.java#L50]
> implementation reflectively calls the old one and always uses the same
> method no matter what overload was called:
> {code:java}
> clazz.getMethod("prompt", String.class, List.class, String.class); {code}
>
> This is incorrect and leads to nullpointers when calling the new prompter
> with just a `message`, but no `possibleValues`.
> The new prompter should delegate to the correct overload of the old prompter
> instead of redirecting all calls to the same method. Also, the nullability
> annnotations are wrong. The message is never nullable. And if an overload
> with `possibleValues` is called, they must not be null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8535) Embedded launcher can't capture Maven 4 output
[
https://issues.apache.org/jira/browse/MNG-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17915811#comment-17915811
]
Stefan Oehme commented on MNG-8535:
---
Yep, tried that one, but it doesn't make a difference.
> Embedded launcher can't capture Maven 4 output
> --
>
> Key: MNG-8535
> URL: https://issues.apache.org/jira/browse/MNG-8535
> Project: Maven
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Priority: Major
>
> We have a lot of tests capturing and validating the output of Maven builds
> and use an embedded launcher by default to make our tests fast. With Maven 4
> and CliNG, our embedder can no longer capture Maven's output. At first I
> thought there was something wrong with our embedder, but I can reproduce this
> with the EmbeddedMavenExecutor provided by the Maven team as well:
>
> {code:java}
> public static void main(String[] args) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> new EmbeddedMavenExecutor(false).execute(ExecutorRequest
> .mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
> .cwd(Paths.get("/path/to/simple-project"))
> .argument("package")
> .stdoutConsumer(out)
> .build()
> );
> System.out.println("Output was: " + out);
> } {code}
> The above program should capture Maven's output, but actually the output is
> dumped directly to the console and the `out` variable remains empty.
>
> This puzzled me, because the embedded launcher [does replace System.out and
> System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
> so it looks like it should work. After some digging I found out that this is
> because of JLine. It doesn't use System.out or System.err, [but instead
> writes directly to the underlying filedescriptors
> |https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
> Please provide a way to capture Maven 4's output with the embedded launcher,
> like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8535) Embedded launcher can't capture Maven 4 output
[
https://issues.apache.org/jira/browse/MNG-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925408#comment-17925408
]
Stefan Oehme commented on MNG-8535:
---
Using CliNg, when I prefil stdin, the input is accepted correctly, but the
prompt is never shown.
When I do the same with the old MavenCLI, the prompt is shown before the input
is accepted.
> And you say that prompt is not shown, so it is not emitted to stdOut?
Correct
> Embedded launcher can't capture Maven 4 output
> --
>
> Key: MNG-8535
> URL: https://issues.apache.org/jira/browse/MNG-8535
> Project: Maven
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> We have a lot of tests capturing and validating the output of Maven builds
> and use an embedded launcher by default to make our tests fast. With Maven 4
> and CliNG, our embedder can no longer capture Maven's output. At first I
> thought there was something wrong with our embedder, but I can reproduce this
> with the EmbeddedMavenExecutor provided by the Maven team as well:
>
> {code:java}
> public static void main(String[] args) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> new EmbeddedMavenExecutor(false).execute(ExecutorRequest
> .mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
> .cwd(Paths.get("/path/to/simple-project"))
> .argument("package")
> .stdoutConsumer(out)
> .build()
> );
> System.out.println("Output was: " + out);
> } {code}
> The above program should capture Maven's output, but actually the output is
> dumped directly to the console and the `out` variable remains empty.
>
> This puzzled me, because the embedded launcher [does replace System.out and
> System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
> so it looks like it should work. After some digging I found out that this is
> because of JLine. It doesn't use System.out or System.err, [but instead
> writes directly to the underlying filedescriptors
> |https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
> Please provide a way to capture Maven 4's output with the embedded launcher,
> like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8535) Embedded launcher can't capture Maven 4 output
[
https://issues.apache.org/jira/browse/MNG-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925401#comment-17925401
]
Stefan Oehme commented on MNG-8535:
---
Latest master works, thank you!
> Embedded launcher can't capture Maven 4 output
> --
>
> Key: MNG-8535
> URL: https://issues.apache.org/jira/browse/MNG-8535
> Project: Maven
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> We have a lot of tests capturing and validating the output of Maven builds
> and use an embedded launcher by default to make our tests fast. With Maven 4
> and CliNG, our embedder can no longer capture Maven's output. At first I
> thought there was something wrong with our embedder, but I can reproduce this
> with the EmbeddedMavenExecutor provided by the Maven team as well:
>
> {code:java}
> public static void main(String[] args) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> new EmbeddedMavenExecutor(false).execute(ExecutorRequest
> .mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
> .cwd(Paths.get("/path/to/simple-project"))
> .argument("package")
> .stdoutConsumer(out)
> .build()
> );
> System.out.println("Output was: " + out);
> } {code}
> The above program should capture Maven's output, but actually the output is
> dumped directly to the console and the `out` variable remains empty.
>
> This puzzled me, because the embedded launcher [does replace System.out and
> System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
> so it looks like it should work. After some digging I found out that this is
> because of JLine. It doesn't use System.out or System.err, [but instead
> writes directly to the underlying filedescriptors
> |https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
> Please provide a way to capture Maven 4's output with the embedded launcher,
> like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8535) Embedded launcher can't capture Maven 4 output
[
https://issues.apache.org/jira/browse/MNG-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925404#comment-17925404
]
Stefan Oehme commented on MNG-8535:
---
One small difference I noticed in the Prompter behavior:
With the old MavenCLI/Maven 3, the interactive prompt is still displayed. With
CLIng, the prompt is not shown, because the embedded runner treats it as
non-interactive. Is it possible to retain the old behavior, so we can test
interactivity with the embedded runner?Testing with embedded mode is much more
convenient, because you have a faster debugging loop than when using a forking
runner.
> Embedded launcher can't capture Maven 4 output
> --
>
> Key: MNG-8535
> URL: https://issues.apache.org/jira/browse/MNG-8535
> Project: Maven
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> We have a lot of tests capturing and validating the output of Maven builds
> and use an embedded launcher by default to make our tests fast. With Maven 4
> and CliNG, our embedder can no longer capture Maven's output. At first I
> thought there was something wrong with our embedder, but I can reproduce this
> with the EmbeddedMavenExecutor provided by the Maven team as well:
>
> {code:java}
> public static void main(String[] args) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> new EmbeddedMavenExecutor(false).execute(ExecutorRequest
> .mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
> .cwd(Paths.get("/path/to/simple-project"))
> .argument("package")
> .stdoutConsumer(out)
> .build()
> );
> System.out.println("Output was: " + out);
> } {code}
> The above program should capture Maven's output, but actually the output is
> dumped directly to the console and the `out` variable remains empty.
>
> This puzzled me, because the embedded launcher [does replace System.out and
> System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
> so it looks like it should work. After some digging I found out that this is
> because of JLine. It doesn't use System.out or System.err, [but instead
> writes directly to the underlying filedescriptors
> |https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
> Please provide a way to capture Maven 4's output with the embedded launcher,
> like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8535) Embedded launcher can't capture Maven 4 output
[
https://issues.apache.org/jira/browse/MNG-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925413#comment-17925413
]
Stefan Oehme commented on MNG-8535:
---
Sorry, the problem was in our test code - We have code to strip out ANSI color
codes to make output matching easier. The new JLine interactivity uses a CSI
escape code to enable "bracketed paste mode" when it prompts for user input.
The old plexus interactivity didn't do that. So I just need to improve our test
code to handle this escape sequence properly.
> Embedded launcher can't capture Maven 4 output
> --
>
> Key: MNG-8535
> URL: https://issues.apache.org/jira/browse/MNG-8535
> Project: Maven
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 4.0.0-rc-3
>Reporter: Stefan Oehme
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> We have a lot of tests capturing and validating the output of Maven builds
> and use an embedded launcher by default to make our tests fast. With Maven 4
> and CliNG, our embedder can no longer capture Maven's output. At first I
> thought there was something wrong with our embedder, but I can reproduce this
> with the EmbeddedMavenExecutor provided by the Maven team as well:
>
> {code:java}
> public static void main(String[] args) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> new EmbeddedMavenExecutor(false).execute(ExecutorRequest
> .mavenBuilder(Paths.get("/path/to/apache-maven-4.0.0-rc-3-SNAPSHOT"))
> .cwd(Paths.get("/path/to/simple-project"))
> .argument("package")
> .stdoutConsumer(out)
> .build()
> );
> System.out.println("Output was: " + out);
> } {code}
> The above program should capture Maven's output, but actually the output is
> dumped directly to the console and the `out` variable remains empty.
>
> This puzzled me, because the embedded launcher [does replace System.out and
> System.err|https://github.com/apache/maven/blob/master/impl/maven-executor/src/main/java/org/apache/maven/cling/executor/embedded/EmbeddedMavenExecutor.java#L148],
> so it looks like it should work. After some digging I found out that this is
> because of JLine. It doesn't use System.out or System.err, [but instead
> writes directly to the underlying filedescriptors
> |https://github.com/jline/jline3/blob/4504b461ba719749d9d9276be11df26d4524914a/terminal/src/main/java/org/jline/terminal/impl/DumbTerminalProvider.java#L50]
> Please provide a way to capture Maven 4's output with the embedded launcher,
> like we used to be able with Maven 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8648) Concurrent executor fires wrong ProjectStarted event
Stefan Oehme created MNG-8648: - Summary: Concurrent executor fires wrong ProjectStarted event Key: MNG-8648 URL: https://issues.apache.org/jira/browse/MNG-8648 Project: Maven Issue Type: Bug Components: Core Affects Versions: 4.0.0-rc-3 Reporter: Stefan Oehme When using the new `-b concurrent` builder, the ProjectStarted event is fired without the current project being set on the Session. This breaks all kinds of event listeners in our Maven extension. The code that [attaches the project |https://github.com/apache/maven/blob/d7cada9c0b49c5f7ac7aced52498e354877333b1/impl/maven-core/src/main/java/org/apache/maven/lifecycle/internal/concurrent/BuildPlanExecutor.java#L378]to the current Thread/Session currently only happens for the actual Mojo execution, but not for the [Setup step|https://github.com/apache/maven/blob/d7cada9c0b49c5f7ac7aced52498e354877333b1/impl/maven-core/src/main/java/org/apache/maven/lifecycle/internal/concurrent/BuildPlanExecutor.java#L378] where the ProjectStarted event is fired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
