Is `Tasks.doNotTrackState` limited to Copy tasks?

Help/Discuss
1

Based on the description of Tasks.doNotTrackState, it is supposed to be used for a problem category that is related to Copy tasks, however I am wondering if it can be used in a more generic manner, for example to do replace an older API for turning off up-to-date checks:

tasks.register('myAdhocTaskThatHasNoTrackableInputs') {
    doNotTrackState 'This task should not have up-to-date checks...'
    // Previously wrote: outputs.upToDateWhen { false }
}

Real-life tasks could be anything whose inputs/outputs should not be tracked, for example:

  • Starts/stops services/daemons
  • Communicates with external services without depending on inputs

Thanks in advance.

2

Hi,

yes, the Task.doNotTrackState is meant to be used for other tasks than the copy task. For example your use-case is described here: Authoring Tasks

The documentation you are referring to are the upgrading notes, where we suggest to use the new method for fixing some deprecation warnings.

Cheers,
Stefan

3

Thanks, @Stefan_Wolf.

I still got problems though.

Release notes

I understand but even in the release notes where I kind of expect a more generic description of the problem, the same tie to the Copy task is described. I was expecting something less confusing, like, hey we added this new feature, but no, not just for that type of task… I think we can expect a little more clarity in the release notes that should explain what new features were added, and what’s in it for me. If I see it’s only for the Copy task, because that’s what I see, then how am I supposed to know that I’m wrong?

Coding consistency

There is also 1 thing I don’t understand and irritates me every time: coding inconsistency. Compare:

tasks.register('alwaysInstrumentClasses', Instrument) {
    classFiles.from layout.files(tasks.named('compileJava'))
    // ...
    doNotTrackState("Instrumentation needs to re-run every time")
}

Do you see the inconsistent use of optional parentheses and the mixed quoting styles? This is terribly frustrating for me because everyone copies your guide and they take it as “sacred”, thus inconsistent styles will be mass-produced throughout the world. If we didn’t have The Apache Groovy programming language - Style guide and Use Groovy consistently (Gradle best practice tip #18) - YouTube then we would be in an even worse place, I guess, although they seldom help the world due to copy-pasting and then being lazy about worrying about coding styles. I get it, you want to focus on Kotlin, but at the same time you abandoned your old coding styles so now there’s a mixup.

4

Hi again,

thank you for your feedback!

In the release notes, there is also a generic description of the problem in the section for plugin authors: Gradle 7.3 Release Notes
We should probably have linked the section from the one about the copy task.

About the code style: Yeah, we probably should have used from() with the braces. And use either ' for the string in doNotTrackState or convert all the other quotes to ". Note that we don’t want to focus on Kotlin DSL necessarily, we are committed to keep both DSLs around.
What we strive to do here is to have the two DSL samples somewhat consistent, so there isn’t much noise when switching between the two. Do you want to do a PR to fix the style in the sample?

Cheers,
Stefan

5

Oh, I see, I somehow didn’t read the section about plugin development… But to be fair, a section alone should be coherent enough on its own, because you know what readers do: they optimize… (And yes, this can also mean adding the right links.)

I’ll consider the PR (last time I was too busy for a similar offer, this time vacation time is coming, so we’ll see). However, some common Groovy style should be established, as right now I see there isn’t much. I’ve been so far doing this:

  • Use apostrophes if we don’t want string interpolation, otherwise quotes (the official Groovy style guide suggests this for readability).
  • I thought the idea of a Groovy DSL was to be a DSL, thus removing a lot of punctuation where not needed. Now we seem not to follow this anymore.

At the end of the day, I don’t mind what style we do, but I prefer consistency. And it’s hard to do a PR if we don’t have that and doesn’t everyone (or most co-authors) follow it. And I hope that plugin authors still using/supporting the Groovy DSL will more often than not pick up what Gradle does.

6

@Stefan_Wolf , would it be possible to establish some style conventions first?

7

Hi.

We want to establish some style conventions, though we didn’t get to that, yet. And I don’t have an estimate when we will have time to establish a style guide.

Cheers,
Stefan