Multiproject checkstyles not working


(Ryan McLaughlin) #1

I am trying to setup checkstyle to work with a multiproject repository

Here is what I have so far

subprojects {
    apply plugin: 'checkstyle'

    task checkstyle(type: Checkstyle) {
        doLast {
            ignoreFailures = true
            source 'src'
            include "*/.java"
            exclude "/test/"
            reports {
                xml.enabled = false
                html.enabled = true
                html {
                    destination file("$project.buildDir/reports/checkstyle/${project.name}.html")
                }
            }
            classpath = files()
        }
    }
}

But it does not find any source

> Task :connect-smt-partition:checkstyle NO-SOURCE
Putting task artifact state for task ':connect-smt-partition:checkstyle' into context took 0.0 secs.
Skipping task ':connect-smt-partition:checkstyle' as it has no source files and no previous output files.

:connect-smt-partition:checkstyle (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
:streams-scenario-check-beats:checkstyle (Thread[Task worker for ':',5,main]) started.

I know I am probably missing something simple


(James Justinic) #2

Your configuration of the checkstyle task definitely shouldn’t be in the doLast { }. It won’t configure anything unless it runs and it won’t run when nothing is configured.


(Ryan McLaughlin) #3

Thanks for the response, I removed the doLast, but the results are still are the same.


(James Justinic) #4

Your include is also suspect. I doubt you want hidden files name .java in any directory or .java files ending in slash. Your probably want include "*.java" or include "**/*.java".

Although, is there a reason you’re not using the task checkstyleMain that is already configured to similarly? You can apply the plugin and tweak the configuration without defining a whole new task from scratch.


(Ryan McLaughlin) #5

Thanks again for the response. At this stage I would rather include too many files and trim it down once I know it works.

I don’t know that I have a good reason to not use checkstyleMain. I am new to Gradle and I was following this thread to get findbugs working Creating common task for all subprojects and I was hoping that checkstyle would be similar in implementation

subprojects {
    apply plugin: 'findbugs'

    task findbugs(type: FindBugs) {
        ignoreFailures = true
        effort = "max"
        reportLevel = "low"
        classes = files("${project.buildDir}/classes")
        source 'src'
        include "*/.java"
        exclude "/test/"
        reports {
            xml.enabled = false
            html.enabled = true
            html {
                destination file("$project.buildDir/reports/findbugs/${project.name}.html")
            }
        }
        classpath = files()
    }
}

(James Justinic) #6

Then you probably want include "**/*.java" (any .java file in any subfolder, except for /test/ due to the exclude). The include "*/.java" is probably a typo in the original post. I can’t think of anything sensible that would ever match that pattern.

The apply plugin: 'checkstyle' creates the tasks checkstyleMain for src/main/java and checkstyleTest for src/test/java (no relation to a Main class to address your original edit). It will automatically run with the lifecycle tasks check and build unless you do something to circumvent that behavior, or disable these tasks. You may wish to disable checkstyleTest if the exclude "/test/" is due to never wanting to run checkstyle on unit test code. There’s nothing in your post that suggests you would do anything other than add needless complexity by not using checkstyleMain.

P.S. That thread you referenced is not a good example of Gradle best practices.


(Ryan McLaughlin) #7

Thanks, I will try using checkstyleMain and see if I can get that to work.

Concerning the referenced thread. Us noobs have to rely on whatever resources we can, and there were no good examples of configuring checkstyle or findbugs for a multi project repo so I had to use whatever I could find. Thanks for pointing me straight.