@kwin I think it would be interesting to add pointers to the code where those exceptions are actually handled ? I must admit I tried to find them but I haven't been able to find them in a timely manner. For example there's no BUILD ERROR string in the whole codebase...

@gnodet Indeed I couldn't find anything either yet. TBH I have just taken the information from https://books.sonatype.com/mvnref-book/reference/writing-plugins-sect-custom-plugin.html#writing-plugins-sect-failure which I consider a pretty reliable source. But maybe the different handling of those exceptions has vanished over time. Will do some more tests....

I tried it out with a dummy mojo and both exceptions behave exactly the same, i.e. both emit "BUILD FAILURE". I couldn't influence the build outcome with any of the --fail-xxx options nor continue the build after the exception happened. I had a quick look in the commit logs and found (06dc81b#diff-976d393f31905911c189adc496696a5047b0aae4526ba1c5d13bf7502ce2cbca) which once treated MojoExecutionException separately, but that class has been removed in ae1501b (with Maven 3), so most probably having two different exception classes is no longer useful in Maven 3...

Given that, I would recommend to either reestablish the different semantics or deprecate one exception class of the two. In any case right now it is highly confusing why there are two different exception classes and when to use which in mojos.

Dug a bit deeper and found

Dug a bit deeper and found

maven/maven-core/src/main/java/org/apache/maven/DefaultMaven.java

Lines 235 to 255 in ed370a6

	else if ( exception instanceof MojoFailureException )
	{
	MojoFailureException e = (MojoFailureException) exception;
	logFailure( response, e, e.getLongMessage() );
	}
	else if ( exception instanceof MojoExecutionException )
	{
	// TODO: replace by above
	if ( exception.getCause() == null )
	{
	MojoExecutionException e = (MojoExecutionException) exception;
	logFailure( response, e, e.getLongMessage() );
	}
	else
	{
	// TODO: throw exceptions like this, so "failures" are just that
	logError( response );
	}
	}

for the different handling.

Now, the exceptions are handled in BuilderCommon and no case is done whether the exception is a MojoFailureException or MojoExecutionException which is coherent with your experiments. If we confirm this, I'd change the javadoc and eventually deprecate one of the exceptions.

My understanding was that MojoExecutionException is a wrapper around another exception as primary usage whereas MojoFailureException is a root exception by itself (and previous handling tends to confirm it).

Overall the need of these exception is that mojo don't throw an Exception/Throwable but there is no technical reason - in particular now, so ultimately we can just deprecate both and change mojo contract for 4.0, no?

Overall the need of these exception is that mojo don't throw an Exception/Throwable but there is no technical reason

I think the reason is to throw an exception which would allow Maven to continue (by using --fail-never or --fail-at-end, https://maven.apache.org/ref/3.8.4/maven-embedder/cli.html). Using an unchecked exception will IMHO always lead to an immediate failure and broken Maven build.

@kwin not sure, --fail-never will ignore the exception and --fail-at-end will stack it to fail after other modules build so MojoXXXExceptons never bring anything in this logic (as proven by BuilderCommon impl) so think it is fine to remove this constraint. There is no real recovery exception in maven - and don't think we need one.