I've got a generic task in my Gradle build that copies some configuration files to be included in the build, but aren't required for compiling or anything else (they're used at runtime). Basically:
val copyConfiguration by tasks.registering(Copy::class) {
from("${projectDir}/configuration")
into("${buildDir}/")
}
This however leads to an issue in every other task as I now get the Gradle warning about how the tasks use this output without declaring an explicit or implicit dependency
Execution optimizations have been disabled for task ':jacocoTestCoverageVerification' to ensure correctness due to the following reasons:
- Gradle detected a problem with the following location: '...'. Reason: Task ':jacocoTestCoverageVerification' uses this output of task ':copyConfiguration' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
Now this is only a warning, and the build succeeds, and my service starts up and runs fine. But it does clog my output making it harder to find the line where something went wrong and is in general an eyesore. I'd like to somehow remove that warning. I saw (from the wiki) that the general solution for this is to write an explicit dependency in the task definition, but since this is happening for every task (from compile, to test, to ktlint, to jacoco, etc.) I don't really want to do that.
Is there an alternative, like an anti-dependency, wherein I can tell Gradle that it shouldn't care about the output of the :copyConfiguration task?
Given (emphasis mine to show what to look for)
Execution optimizations have been disabled for task 'spotlessJava' to ensure correctness due to the following reasons:
Gradle detected a problem with the following location: '...\build\generated\source\proto\main\grpc'. Reason: Task 'spotlessJava' uses this output of task 'generateProto' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
Add the following to build.gradle
tasks.named("spotlessJava").configure { dependsOn("generateProto") }
I had a similar issue and funny that it started with a task related to Jacoco.
I documented a solution here https://discuss.gradle.org/t/task-a-uses-this-output-of-task-b-without-declaring-an-explicit-or-implicit-dependency/42896
In short, what worked for me was to get the location with the problem using the task properties, e.g. getOutputs.
Hope this helps.
Related
It was known a while back that Gradle cached Java modules when doing incremental builds. Meaning modules A, B, & C with changes just done to A, would just require rebuilding of A alone.
However, in reading their documentation see no mention of module caching. It seems to be more general than so.
Can anyone confirm module was a thing of the past? Also if modules help reduce times with incremental builds nowadays?
Yes, tasks provided by Gradle itself (incl. by built-in plugins like java) generally try to be incremental, i.e., tasks with up-to-date outputs on disk won’t re-run. See also this doc section which says:
Most tasks provided by Gradle take part in incremental build because they have been defined that way.
IDEA. For most time, when I modify a build.gradle file. It takes a long time to importing or sync the changes. What does it doing? How can I see action details.
IntelliJ has to run the gradle build file to import its configuration. Sorry I don't remember what exact task it runs.
When Gradle runs any task, it first has a configuration stage where it reads through all of the build files and gets ready to run tasks. For larger build files this can take quite some time.
To find out what is taking Gradle so long, check out the "Build Scans" section and other performance optimization tips here: https://guides.gradle.org/performance/
I have recently started using gradle in a project and I am running the standard
gradle clean init build
I noticed that in many of the tasks that are running, I get this UP-TO-DATE message in the console, next to the current task that's running. eg:-
:foo:bar:test UP-TO-DATE
I am curious as to what does this message mean. Couldn't find any documentation around the same.
Everything that Gradle does is a task. Most tasks have inputs and outputs declared. Gradle will determine if a task is up to date by checking the inputs and outputs.
For example, your compile task input is the source code. If the source code hasn't changed since the last compile, then it will check the output to make sure you haven't blown away your class files generated by the compiler. If the input and output is unchanged, it considers the task "up to date" and doesn't execute that task. This can save a lot of time, especially on large builds.
BTW: In case you really want to bypass this build optimization, you can use the --rerun-tasks command-line option to enforce execution of every task.
see documentation of gradle command-line options
Gradle is an incremental build system. This means that it checks that a task must really be executed before actually executing it, in order to be faster.
So, for example, if you already compiled your source files in a previous build, and didn't modify any source file (nor any other input of the compile task), then Gradle won't recompile all the source files, because it know it will lead to exactly the same output as the one already present in the build folder. And the compilation is thus safely skipped, leading to a faster build.
More information in the documentation
I faced the similar problem tried all the options, but the following one worked for me:
gradle -Dorg.gradle.daemon=false <your tasks>
We have a strange issue where randomly and infrequently, the compileJava task which deletes the META-INF folder and compiled classes to start, runs but the processResources task reports up-to-date, even though the META-INF directory clearly doesn't exist.
This bites us big time because it's possible that the artifacts make it all the way to production without an applicationContext.xml!
It costs very little for us to run that task, is it possible to force it to run, no matter what?
Maybe there's some kind of bug that fails to clear gradle cache. One possible solution would be to first force the task to clean its own output by running cleanProcessResources.
If that does not work then try overriding the upToDateWhen predicate of your task's outputs like this:
processResources.outputs.upToDateWhen{ false }
However I don't know if this API is permanent.
I'm playing with the wonderful FindBugs plugin for Hudson. Ideally, I'd like to have the build fail if FindBugs finds any problems. Is this possible?
Please, don't try and tell me that "0 warnings" is unrealistic with FindBugs. We've been using FindBugs from Ant for a while and we usually do maintain 0 warnings. We achieve this through the use of general exclude filters and specific/targeted annotations.
The hudson way is to use unstable and not fail for something like this.
However if you really do want your build to fail, you should handle this in ant.
<findbugs ... warningsProperty="findbugsFailure"/>
<fail if="findbugsFailure">
Maybe you've already seen this option, but it can at least set your build to unstable when you have greater than X warnings. On your job configuration page, right below the Findbugs results input field where you specify your findbugs file pattern, should be an 'advanced' button. This will expand and give you an "Unstable Threshold" as well as Health Reporting that changes Hudson's weather indicator for the job based on the number of warnings.
I wouldn't want my build to fail, but unstable seems reasonable if you are maintaining 0 warnings (and presumably 0 test failures).
As Tom noted, the provided way to do this is with the warningsProperty of the FindBugs ant task.
However, we didn't like the coarse control that gave us over build failure. So we wrote a custom Ant task that parses the XML output of FindBugs. It will set one Ant property if any high priority warnings are found, a different property if any correctness warnings are found, a third property if any security warnings are found, etc. This lets us fail the build for a targeted subset of FindBugs warnings, while still generating an HTML report that covers a wider range of issues. This is particularly useful when adding FindBugs analysis to an existing code base.
You can not rely on find bugs so much , it is just an expert system that tells you that something may be wrong with your program during runtime. Personally I have seen a lot of warning generated by findbugs because it was not able to figure out the correctness of code (in fact).
One example when you open a stream or jdbc connection in one method and close it in other, in this case findbugs expecting to see close() call in same method which sometimes is impossible to do.