Feature Request: Provide a new API TaskInputs#upToDateWhen


(Etienne Studer) #1

Similar to what is already available on TaskOutputs#upToDateWhen, provide a semantically similar API on the TaskInputs interface. http://www.gradle.org/docs/current/javadoc/org/gradle/api/tasks/TaskOutputs.html#upToDateWhen(groovy.lang.Closure)

Currently, I need to ‘abuse’ the TaskOutputs#upToDateWhen API to declare a custom condition that is semantically an ‘input’ to the task and not an ‘output’ of the task.


(Luke Daley) #2

Can you dig into your use case a bit more?

The concept of up-to-date doesn’t really apply to inputs. Inputs could be “unchanged” though.


(Etienne Studer) #3

Use case: a task needs to be executed if the database is in a certain state (e.g. the schema is not yet initialized). I cannot express this through @InputFile, of course. Thus, I need to be able to add a closure that allows me to implement a custom check to see whether the database is in a uptodate state (no need to run the task) or if it is in a outofdate state (task needs to be run). This closure (or closures) should be defined on the inputs of the task.

Maybe upToDateWhen is the wrong name, maybe it should be called something more like unchangedWhen, like you suggested.


(Luke Daley) #4

Isn’t the schema the output here though?


(Perryn Fowler) #5

Hi Etienne,

Could you give us more information about your specific use case? (From this and the other thread I have been able to glean that you have a task that generates some sort of code from input files and that this also has something to do with the current state of the DB schema). I’m guessing it has something to dowith generating DB upgrade scripts or DB access code?

Perryn


(Etienne Studer) #6

Correct, Perryn. The schema present in the database serves as the input from which the source code is generated. The config file declares where the schema can be found, i.e. the db connection parameters. Thus, the db schema present in the database and the config file are the inputs and the generated source code is the output. Btw, the generated source code provides a small abstraction over sql to interact with the given database schema.

I only want to generate the source code if the schema has changed in the database. I implement the logic myself on how to detect if the schema has changed in the database -> that’s why I need the new API on the TaskInputs.

This is a concrete use case that I’m currently implementing in a gradle plugin, but I think the ‘problem’ is applicable in a more general sense: inputs can be more than just file-based and therefore the user should have a chance to define these custom inputs.


(Luke Daley) #7

Can you hash the DB state to a value? If so, you can use that value as an input…

task.inputs.property("dbState", { connectToDbAndGetStateHash() })

(Etienne Studer) #8

Interesting. That could work. Though it seems more like a work-around to get my problem at hand solved than a true solution of the underlying, more general problem. Looking at my current plugin code, the solution with TaskOutputs#upToDateWhen reads quite nice, except the semantic error that the closure applies to the inputs in reality.

Also, currently, in my concrete use case, I have a separate Gradle task that generates the schema in the database and in my “uptodate condition” closure, I query that task if it executed some work. If it did, the schema is outofdate. Hence, rather than a hash value I currently have a true/false answer from another task that I use to decide if the source code generation task is uptodate or not.


(Etienne Studer) #9

I think this feature request deserves a JIRA issue. Shall I create one or will the Gradleware team create it?