olamy commented on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1066006526
> @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. Please provide a link. > 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. > what is the difference for the end user if term of build result and output? > 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. I do not point any fingers on anybody. I'm just saying this code not worth it and can be simplify as it doesn;t bring any value for end user. The result is same. so if we can simplify a bit the surefire code that will be great. The code exists because it has been created with maven2 but doesn't have any sense anymore now with maven3 So **again** it can be simplified and I'm not blaming anybody. > > 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. > please provide some example projects as I don't really understand your point here. and especially in a user point of view. > 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, again please read my arguments below or have a look at the sample project provided, APIs > 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. > it's not related to this PR and would be better to add comments here https://github.com/apache/maven-surefire/pull/478 But anyway I will comment here a bit with some real use case and user experience. The goal of `-Dmaven.test.failure.ignore=true` is to ignore test failure and print a BUILD SUCCESS at the end even if some tests has failed. As stated in the documentation, This option is explicitly `NOT RECOMMENDED`. The use case is to have a build which run all the the tests and some tooling will give a global result of tests which has been runned. Still giving a BUILD SUCCESS even if some tests has failed but some CI such Jenkins collect the results and can eventually mark the result as unstable or fail but you need the help of another tooling. But in some misconfiguration the tests are not even running so the proposed change https://github.com/apache/maven-surefire/pull/478 . **not being able to run the tests is a very different case than running tests and have test failure.** Use case (and I have encountered this real life problem), huge build with a lot modules, this build is configured with the ignore option and run on Jenkins with a matrix of 3 os and 6 jdks. (different profiles for each jdk with some different jvm args) With this option activated and some wrong jvm arguments, one of the modules can totally fail in this big matrix of build but nobody will notice it as the result is always success and the tests didn't even run. So even Jenkins will not collect anything. > 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. please provide example with some real difference in a user point of view or final build output. -- 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
