"Augment xml" and "Reduce xml" - resolving cyclic task dependencies


(Jonas Gustavsson) #1

I’m working with a quirky IDE that declares build modules in some xml files. These xml files is an unfortunate mix of stuff I want checked in and IDE-generated stuff that I do NOT want to check in (because they grief me with constant source control conflicts).

My planned solution was to set up Gradle tasks to sort this out:

  1. Store partial xmls along with the module source, this is what gets checked in
  2. One task “augmentXML” that reads the partial xml source, adds relevant elemts to it and writes the result to the IDEs workspace.
  3. One task “reduceXML” that reads the augmented xml from the worskpace, removes the silly stuff that should not get checked in and writes the result in the source folder structure.
  4. Run Gradle with above tasks in continuous mode, keeping the IDE workspace in sync with the actual source structure regardless of where changes were introduced.

Now, weathered gradleers will start shaking their heads in dismay because these tasks define a cyclic dependency: augmentXML depends on output from reduceXML, which in turn depends on output from augmentXML. Indeed, this approach does not work as-is. Gradle will decide a task order and then execute both tasks based on that regardless if the change was in the source xml or the generated xml.

Can my desired behavior be modeled somehow?
I think I need to enforce a dynamic task ordering scheme, where a task with changed inputs take precedence over a task with changed outputs. Can this be done?
There are various mechanisms in gradle I could try, like using shouldRunAfter or custom upToDateWhen logic, but I can’t see how…

Does anyone have good ideas on this?