We have an in-house plugin that makes the “build” task call “check”. I want to remove this dependency.
And I want to remove the “check” dependency for all “java” subprojects.
we have code like this:
configure(javaProjects()) {
apply plugin: 'bas-groovy'
apply plugin: 'bas-coins'
}
the “coins” plugin is the one that creates the check dependency.
Thanks in advance!
‘build’->‘check’ is the default. Without this, ‘build’ will no longer run tests etc. ‘build.dependsOn.remove(“check”)’ should work. In general, removing task dependencies is a smell though.
I didn’t realize that “check” was a standard gradle task. The real issue is that “check” has dependencies on a group of tasks declared in the “coins” plugin. And these coins tasks take about an hour.
I think it’s best that we just don’t call build if someone doesn’t have an hour to kill.
Peter,
I wish to remove the checkstyleTest from the check task. Nothing I have done removes it. I tried
check.dependsOn.remove("checkstyleTest")
But that didn’t seem to work. We don’t want to run the same checkstyle rules on our test code that we run on our app code.
See the ‘sourceSets’ property on CheckStyleExtension.
Thanks Peter, but according to the docs, that property defines the source sets used by both the check AND build tasks. I only want to affect the check tasks.
That’s because ‘build’ depends on ‘check’. I’d be reluctant to make ‘check’ behave differently than ‘build’ in this regard, because it is against the expected behavior of these tasks. Instead I would consider adding my own variant of a ‘check’ task, targeted at the specific needs.
If you really want ‘check’ and ‘build’ to behave differently in terms of which CheckStyle tasks they run, you’ll have to resort to conditional configuration using the ‘gradle.taskGraph.whenReady’ idiom. Nevertheless, ‘checkstyle.sourceSets’ remains the way to go.
Abstracting from the concrete problem, whenever possible it’s better to add only what’s needed in the first place, rather than adding too much and then trying to compensate by removing some of it. This applies to many areas of Gradle (plugins, tasks, dependencies, etc.). It’s also usually better to provide multiple variants of something, rather than to make the same thing behave differently under different circumstances (the ‘check’ task in this case).
Thank you for that. Though I agree with you in principal, the idea that the test sourceSets and the app sourceSets should be treated the same for both build and check is not really the case in all circumstances. “build” also depends upon “assemble”. Assemble doesn’t utilize the test sourceSet, or am I wrong there?
In any case. You pointed me in the right direction. For those projects that I don’t what to run checkstyle against any of my test code, I used the taskGraph as you indicated, but I used the beforeTask to remove all of the “checkstyleTest” tasks actions :-). I’ll probably get a little more clever later and just point the checkstyle configFile to a different set of rules that I want to apply to my test code, if I find that I can change that on the fly.
gradle.taskGraph.beforeTask { task ->
if ( task.name == "checkstyleTest"
) {
task.deleteAllActions()
println "Task $task.name is being rendered useless"
}
}
That’s doesn’t achieve what you originally stated as a goal (run all checkstyle tasks when calling ‘build’, and only a subset when calling ‘check’.) A much simpler solution that will achieve exactly the same as this code is ‘checkstyleTest.enabled = false’. Or even better, ‘checkstyle.sourceSets = [sourceSets.main]’. Which brings us back to my first answer…
the idea that the test sourceSets and the app sourceSets should be treated the same for both build and check is not really the case in all circumstances. “build” also depends upon “assemble”. Assemble doesn’t utilize the test sourceSet, or am I wrong there?
The idea is that a task’s task dependencies are “stable” and aren’t a function of whether the task gets invoked directly or not (because that would make it very hard to reason about the task). This principle also holds for assemble.
Well, I never stated that as a goal 
My specific goal is to run a different set of checkstyle rules on my test code ( a little less restrictive ), than I do on my app code. My first step was just to not run checkstyle on my test code at all, until I figured out how to do my main objective.
But, the checkstyleTest.enabled = false worked like a charm. I removed the taskGraph related code.
I’m still a relative noob to Gradle, so manipulating in the configuration of plugin tasks is still pretty new to me. I’m trying to put these configurations into a plugin .gradle file that my projects import with an apply from: This keeps my project build files fairly clean, mostly just jar names and dependencies.
Thanks for your help. We had Peter Walker here at our company last month, but I had to travel out of town when he was here. I would have bothered him with this stuff
Thanks Peter
I used your second fix.
My big problem was where I was trying to add the suggested code in my plugin.
It didn’t allow me to set the sourceSets on checkstyle where I was trying to do it. If I do this:
plugins.withType(JavaPlugin) {
....
checkstyle.sourceSets = [sourceSets.main]
....
}
It seems to work fine. Thank you for your patience with an old noob. I certainly got an education in this case.
George
I see. Yes, depending on the nature of your plugin you may have to make sure to only do this for projects that have the CheckStyle plugin applied. (Another potential option, which may or may not fit your needs, would be for your plugin to apply the CheckStyle plugin.) The way to do this is ‘project.plugins.withType(CheckStylePlugin) { … }’ (not ‘withType(JavaPlugin)’). This is just another callback that acts as a fancy if-statement and will do the right thing even if the CheckStyle plugin will only get applied after your plugin.
Yes, thank you Peter. My plugin forces all java plugin projects to have checkstyle, cobertura, findbugs, and artifactoryPublish plugins configured.
I thought about using the withType CheckStylePlugin instead of/ or in addition to the JavaPlugin, but couldn’t get that to work. I’ll look into it more, now that I have a better understanding as to what I’m doing