[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1066108404 @slawekjaranowski I know what you mean and I agree with you. I only want to say that we should go step by step. First, the Javadoc should be fixed in the API due to we forgot it as it seems. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1066108404 @slawekjaranowski I know what you mean and I agree with you. I only want to say that we should go step by step. First, the Javadoc should be fixed in the API. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1066090993 @olamy @slawekjaranowski @hboutemy We should discuss one extra topic in the mailing list _dev@maven.apache.org_ with a topic related to the findings we have observed in this PR. I am convinced that the issue with _BUILD FAILURE/ERROR_ of the exceptions _MojoExecutionException/MojoFailureException_ is not a problem of this plugin itself. I have talked about it with @hboutemy and we launched the project [1] given by @olamy . If you strictly follow the Javadoc of these exceptions in the API 3.2.5, you would see a difference between the text and the current behavior of Maven Core 3.x. We should agree on what would be done with this misconception, whether we will adapt the Javadoc in favor of Maven Core or opposite, plus some technical details... I don't want to be the one who takes the responsibility, we all should inform the team about the difference between the reality and Javadoc. Since it looks like a trivial issue, it can be discussed in the mailing list and the steps can be defining a fix. Pls let me open the discussion, feel free to provide your opinions and fix proposals. Thx [1]: https://github.com/olamy/maven-exception-plugin -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1066090993 @olamy @slawekjaranowski @hboutemy We should discuss one extra topic in the mailing list _dev@maven.apache.org_ with a topic related to the findings we have observed in this PR. I am convinced that the issue with _BUILD FAILURE/ERROR_ of the exceptions _MojoExecutionException/MojoFailureException_ is not a problem of this plugin itself. I have talked about it with @hboutemy and we launched the project [1] given by @olamy . If you strictly follow the Javadoc of these exceptions in the API 3.2.5, you would see a difference between the text and the current behavior of Maven Core 3.x. We should agree on what would be done with this misconception, whether we will adapt the Javadoc in favor of Maven Core or opposite, plus some technical details... I don't want to be the one who takes the responsibility, we all should inform the team about the difference between the reality and Javadoc. Since it looks like a trivial issue, it can be discussed in the mailing list and the steps can be defining a fix. Pls let me open the discussion, provide your opinions and fix proposals. Thx [1]: https://github.com/olamy/maven-exception-plugin -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe an ego benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure due to the JVMs have been timed out and stopped - the JVM was stopped abruptly - with an exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe an ego benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of them knew that it should be called this way. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of them knew that it should be called this way. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter our all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
