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 woul
