search

stevesaliman / gradle-cobertura-plugin

Gradle Cobertura Plugin
118 stars 50 forks source link

When running with --dry-run command line, the plugin complains about a missing coverage data file #64

Closed maddingo closed 9 years ago

maddingo commented 9 years ago

Because --dry-run doesn't actually run the instrumentation the coverage data file is not created. When running with --dry-run, the CoberturaRunner should not actually run cobertura but quietly return. I provided a pull request (#66) that addresses this issue.

stevesaliman commented 9 years ago

I tested pull request #66, but it doesn't fix the problem.

When Gradle does a dry-run, it should skip all tasks. Because tasks are skipped, Gradle won't assume they are up to date the next time Gradle runs.

With pull request #66, the tasks still run, they just don't do anything. Because of this, the next time Gradle runs, it thinks the instrument task is up do date, but the copyCoberturaDataFile task fails because there is no .ser file.

To reproduce this, go to the test client directory and type gradle clean, then gradle -m cobertura, then gradle cobertura. The first two run fine, but the last one fails.

It appears as if Gradle itself is supposed to "disable" all tasks when it detects the dry run parameter, but for some reason, it isn't doing it to the Cobertura tasks. I think that is the issue we need to solve. I wonder if the tasks are being defined in a way that Gradle doesn't see them?

stevesaliman commented 9 years ago

I think I've found the problem. When the plugin is applied, it assumes that certain tasks, such as instrument should be disabled, so it registers a listener that looks at the task graph just before execution. If that listener detects that the user wants a coverage report, it enables the tasks that do that work. That listener should have taken the dryRun parameter into effect, but it didn't. I've fixed that bug and uploaded the latest source code. This is causing issues with unit tests, which I'm trying to fix now.

maddingo commented 9 years ago

Excellent, I suppose my patch was a bit of a long shot. I didn't run the code in the debugger. I guess I have to set up my Eclipse environment properly to run the plugin in Eclipse. I you have any advise on how to set up Eclipse I would be grateful.

stevesaliman commented 9 years ago

My original push didn't go out like I thought it did. It should be there now.

I've been using IntelliJ Idea for a while, so I'm not sure exactly how to configure eclipse, to run a build in Idea, I had to do the following:

  1. Add -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y to the GRADLE_OPTS environment variable
  2. Create a new "remote" run configuration that attaches to localhost, port 5005.

Then when I run gradle form the command line, it stops and waits for a JPDA connection. When I run my new "remote" connection in Idea, it connects to the gradle process and I can step through the code.

stevesaliman commented 9 years ago

This has been fixed in release 2.2.6, which was released this morning.