maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tibor Digana (JIRA)" <>
Subject [jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
Date Thu, 05 Oct 2017 08:32:00 GMT


Tibor Digana commented on SUREFIRE-1426:

Again yesterday your problem was the USER ERROR {{Unable to load category: bogusGroup}} because
you did not read documentation properly and did not pass Java class to JUnit group.
Today you are coming with SYSTEM ERROR {{OOM}}.
The system property {{maven.test.failure.ignore}} is not about masking your user error nor
system error. This is about ignoring events coming from JUnit reflecting exception like {{Assumption|AssertionError}}
or ordinal exception caught by JUnit thrown by you test code.
I am no more willing to mask {{OutOfMemoryError}} and not to mask wrong configuration because
otherwise running tests would not makes sense! Then why you executed {{mvn test}} if you do
not expect to run tests? And why you use {{maven.test.failure.ignore}} which everybody knows
that it is highly unrecommended in good s/w development and why you simply did not skip tests
{{-DskipTests}} if you do not like writing and maintaining tests and you do not like high
quality of s/w?

> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> -------------------------------------------------------------------
>                 Key: SUREFIRE-1426
>                 URL:
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: process forking
>            Reporter: Dan Berindei
>            Assignee: Tibor Digana
>         Attachments: surefire-1426-test.tar.gz
> We have a reactor with many modules, and also a few random test failures. We want to
run the tests of all the modules even if a test failed in the core module, so we use {{mvn
-Dmaven.test.failure.ignore=true}}. {{mvn --fail-at-end}} only builds the modules that do
not depend on the module with a failed test.
> The problem is that fork crashes like this one are written to the surefire reports, so
Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the
forked process
> Unable to load category: stress
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(
> 	at
> 	at
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> 	at
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(
> 	at org.apache.maven.DefaultMaven.doExecute(
> 	at org.apache.maven.DefaultMaven.doExecute(
> 	at org.apache.maven.DefaultMaven.execute(
> 	at org.apache.maven.cli.MavenCli.execute(
> 	at org.apache.maven.cli.MavenCli.doMain(
> 	at org.apache.maven.cli.MavenCli.main(
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> 	at java.lang.reflect.Method.invoke(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main({noformat}

This message was sent by Atlassian JIRA

View raw message