Stack trace printed when no test classes are run (Surefire 2.12.2+)

[atomicknight]

Version 2.12.2 of the maven-surefire-plugin includes an optimization that avoids forking the JVM if a fork mode of "once" is specified and there are no tests to run. Consequently, there is no guarantee that the Jacoco data file will be generated, leading to the following stack trace when the above conditions are met:

[ERROR] Unable to read execution data file /home/atomicknight/test/target/jacoco.exec: /home/atomicknight/test/target/jacoco.exec (The system cannot find the path specified)
java.io.FileNotFoundException: /home/atomicknight/test/target/jacoco.exec (The system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:120)
at org.jacoco.maven.ReportMojo.loadExecutionData(ReportMojo.java:251)
at org.jacoco.maven.ReportMojo.executeReport(ReportMojo.java:228)
at org.jacoco.maven.ReportMojo.execute(ReportMojo.java:217)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

I'm not sure how this should be addressed. The simplest solution is to just ignore the missing data file, but that might not be desirable in all situations.

[marchof]

Probably a simple one-line warning would be the best, as proposed here:

http://sourceforge.net/tracker/?func=detail&aid=3563431&group_id=177969&atid=883351

[atomicknight]

Thanks for the feedback and for providing the link to the existing issue. I like the general concept, though I wonder if logging a warning might be too alarming, given that valid configurations would trigger this behavior.

Here's a possible alternative: instead of modifying the default behavior, introduce an "ignoreMissingDataFile" parameter that suppresses the stack trace and replaces it with an INFO message if the file is missing and the setting is set to "true." When set to "false" (the default), the current behavior remains unchanged (though I believe most plugins actually fail the build on error as opposed to just printing the stack trace).

What do you think? I can submit a pull request for this if that'd be helpful.

[marchof]

What if we simply log an INFO message if the file does not exist? (we should still dump an ERROR if the file exists but can not be read).

[atomicknight]

That seems reasonable. Would you like me to submit a pull request? Or is someone already working on it?

[Godin]

Of course feel free to submit pull request - this might speed-up resolution of this issue, however take a look on our conventions http://www.eclemma.org/jacoco/trunk/doc/conventions.html , what implies that patch must be well-formated and tested.

[Godin]

BTW, I can imagine another way to fix this issue: AgentMojo can create an empty jacoco.exec file, thus it will exist even if surefire wasn't executed. Guys, WDYT?

[marchof]

I prefer to separate concerns and go with the proposed fix. There might be scenarios where we want to use agent and reporting separately.

[atomicknight]

Creating the empty file was actually the first approach I tried - it does work, but I think it's a bit questionable in that it creates additional pre-/post-conditions that aren't necessarily obvious at first glance. On the other hand, I can't really think of a use case in which the reporting goal would be used without executing the agent goal first. While I don't think the proposed fix is perfect, I think the separation of concerns argument is still fairly compelling.

[Godin]

Here is my vision:

• Goal of ReportMojo - generate report based on existing dump file.
• Goal of AgentMojo - prepare for collection of coverage.

And now main question here - do we want to stop ReportMojo immediately if dump not exists or not?
I prefer fail-fast approach, because nobody looks into logs, if CI job completed successfully. From here - proposed solution is not good one.

And I don't see how creation of file in AgentMojo breaks concept of separation, because this is exactly the job of AgentMojo - prepare for collection of coverage and this preparation may mean creation of a file.

But maybe I miss something?

[atomicknight]

No, that seems reasonable. I've just been a wary of relying too heavily on side effects, though it's clear that the situation requires them to some degree (though the question is "to what degree?").

I do agree that fail-fast execution is desired here - this is why I consider the proposed solution to be imperfect. I'm really fine with either approach.

[Godin]

Ok, so @marchof we're waiting your decision ;)

[atomicknight]

As a side note, the missing file doesn't actually trigger a build failure - it just prints a stack trace and exits normally. So to actually get that fail-fast behavior, that logic should be modified as well.

[Godin]

@atomicknight good point!

[Godin]

On the other side - no need to create dump file by AgentMojo, if current project even not designed to contain tests (e.g. just to create package with application).

[atomicknight]

I didn't quite follow that last comment - could you elaborate?

[marchof]

What is the exact situation we're targeting here? Is it

• we don't have tests for a module at all
• we want to create an coverage report anyways.

[atomicknight]

For me, the situation is:

• The module contains no tests
• The Jacoco plugin executions are defined in a parent POM
• We don't expect a coverage report even though the plugin runs
• We don't want to see an error message/stack trace being printed during execution of the plugin

[marchof]

From the discussion I don't see a final solution that covers all issues raised here. So my proposal is to go with a slightly modified version of atomicknight's patch as a first step as it improves the current situation a bit:

• We get a proper info log in case of missing exec files (done by the patch)
• We log an error and break the build, if the exec file exists but cannot be read (to be done)

Can we agree on this and open new issues for the other aspects?

[Godin]

LGTM, so I'll do this today.

[atomicknight]

Sounds good. I've updated the pull request to trigger a build failure when the execution data file cannot be read. I wasn't sure if it made sense to log an error in addition to throwing the exception (since the latter prints the message already), but I left it in anyway.

[jglick]

mvn -DskipTests clean install now prints just

[jacoco:report]
Skipping JaCoCo execution due to missing execution data file

which is good. An optimization could be to suppress this message—and also suppress any activity from prepare-agent—when skipTests (or maven.test.skip) is set.

[Godin]

@jglick Feel free to create separate issue.