New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE #486
Conversation
this code could/must be simplified as Maven Core doesn;t make any difference between the 2 exceptions for very long time (i.e first version of maven 3.x) |
throw firstForkException == null | ||
? new MojoExecutionException( msg ) | ||
: new MojoExecutionException( msg, firstForkException ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the difference
MojoExecutionException( msg )
and MojoExecutionException( msg, null )
for both getCause()
will return null
My point is: What is the difference in the output result of a Maven build between MojoFailureException and MojoExecutionException? Please provide some ITs or an example I will be happy to understand |
sample here https://github.com/olamy/maven-exception-plugin the technical comment is all this code can be removed as there is no difference between |
@slawekjaranowski The purpose of both exceptions ( 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 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. These questions regarding existence of exceptions should not be given to me as I am not the author of the Mostly if the |
Please provide a link.
what is the difference for the end user if term of build result and output?
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.
please provide some example projects as I don't really understand your point here. and especially in a user point of view.
again please read my arguments below or have a look at the sample project provided, APIs
it's not related to this PR and would be better to add comments here #478
please provide example with some real difference in a user point of view or final build output. |
@olamy |
Never mind if we use one or two exceptions - this change add code, like: throw firstForkException == null
? new MojoExecutionException( msg )
: new MojoExecutionException( msg, firstForkException ); IMHO it is not necessary the same result is: throw new MojoExecutionException( msg, firstForkException ); we needn't check if cause is null or not |
@slawekjaranowski |
So @Tibor17 what step you achieve by this PR? I see next branch of decision in code (next "if" ) without any result. Maybe I don't see something else with bigger context. |
do you mean that it's not necessarily the same result? (= I don't agree) |
It is not necessary, because it gives the same result. Stack Trace is the same for both constructor. MojoExecutionException( msg )
MojoExecutionException( msg, null ) Checking - if cause has null value or not is redundant. |
@slawekjaranowski I see we agree @Tibor17 this PR does nothing (than adding more lines of code), then IMHO it can/should be simply dropped |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to define what problem is being worked on
The ITs use |
Following this checklist to help us incorporate your
contribution quickly and easily:
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
SUREFIRE-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean install
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean install
).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.