"No mutations found" PitHelpError in multi-module Gradle project

[dljsjr]

I believe my issue may be closely related to #2.

I work with a fairly complex Gradle project layout with hundreds of Gradle projects in various hierarchies. It looks something like this:

Root Project (contains no code)
├── ProjectA
├── ProjectB
├── SuperProjectA (contains no code)
│   └── ChildProjectA
│   └── ChildProjectB
├── ProjectC
└── …

So there are several stand-alone projects, several "projects" that are groupings of other projects, etc. Additionally, projects frequently depend on each other from source rather than from .jar. In IntelliJ parlance, they are Module dependencies rather than Library dependencies.

When I try to run a PIT test, I get the following output:

7:34:35 PM PIT >> INFO : Created  0 mutation test units
Exception in thread "main" org.pitest.help.PitHelpError: No mutations found. This probably means there is an issue with either the supplied classpath or filters.
See http://pitest.org for more details.
    at org.pitest.mutationtest.tooling.MutationCoverage.checkMutationsFound(MutationCoverage.java:267)
    at org.pitest.mutationtest.tooling.MutationCoverage.runReport(MutationCoverage.java:138)
    at org.pitest.mutationtest.tooling.EntryPoint.execute(EntryPoint.java:101)
    at org.pitest.mutationtest.tooling.EntryPoint.execute(EntryPoint.java:43)
    at org.pitest.mutationtest.commandline.MutationCoverageReport.runReport(MutationCoverageReport.java:72)
    at org.pitest.mutationtest.commandline.MutationCoverageReport.main(MutationCoverageReport.java:43)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)

I'm guessing that it's a classpath issue. I'm also wondering if there's possibly a problem with the concept of the "Source dir" entry in the form. I'm assuming that "source dir" assumes a Maven-style project layout, that is, that both Test and Source classes live inside of the same parent directory. Many of our projects predate the popularity of Maven (it's an old code base) and have a "test" directory for test classes and a "src" directory for sources at the top level of the Module, so if the tool is expecting the regular Java files and JUnit Java files to live under the same directory then that could contribute to the problem.