The three basic files of an IntelliJ project - the ipr, iws, and iml files - can be accessed as in gradle in the idea task through

project.ipr
module.iml
workspace.iws

using the .withXml lets you access the xml. Using the .asNode() on that turns it into a groovy xml node.

Ex:

project.ipr.withXml { provider ->
    def node = provider.asNode()

From there it's pretty simple - to modify gradle to configure IntelliJ projects for you, take the file as it starts, perform the actions you'd like gradle to take (inside IntelliJ), and then diff the new file with the old file. You should see what XML you'll need to customize the idea job. You'll also need to take note of where in the xml it's located.

One other thing to consider is that you don't want duplicate nodes within the IntelliJ files if you run the gradle idea multiple times. So, you'll want to search for the node you'd like to make and if it's not there, you can create and insert it.

Pitfalls:

Sometimes, when using == for string comparison in the find method, it fails. When testing and I find that to be the case, I use .contains.

When searching for nodes, not all nodes have the attribute you're using as a criteria, so be sure to check for null.

doLast

Note, that in a gradle 3.x more idiomatic way task definition: using explicit doLast{closure} notation instead "leftShift"(<<) operator preferable.(leftShift has been deprecated in a gradle 3.2 is scheduled to be removed in gradle 5.0.)

task oldStyle << {
    println 'Deprecated style task'
 }

is equivalent to:

task newStyle {
    doLast {
    println 'Deprecated style task'
    }
 }

Please note that mustRunAfter and shouldRunAfter are marked as "incubating" (as of Gradle 3.0) which means that these are experimental features and their behavior can be changed in future releases.

There are two ordering rules available:

• mustRunAfter
• shouldRunAfter

When you use the mustRunAfter ordering rule you specify that taskB must always run after taskA, whenever both taskA and taskB will be run.

The shouldRunAfter ordering rule is similar but less strict as it will be ignored in two situations:

• if using that rule introduces an ordering cycle.
• when using parallel execution and all dependencies of a task have been satisfied apart from the shouldRunAfter task, then this task will be run regardless of whether its shouldRunAfter dependencies have been run or not.