What's the best choice between tasks or methods to organize your Gradle build logic? - methods

Question

I'm currently migrating some old huge Maven 1 script to Gradle.
As a consequence, I need to adapt the old Maven 1 / Ant & its goals logic to Gradle.
After having read the Gradle User Guide, and some articles on Gradle tasks and methods, I am quite confused about the way to write my script.
In the official Gradle User Guide, §6.1, it is explained that a Gradle task:
represents some atomic piece of work which a build performs
In §6.11, it is also explained that we can use methods to organize our build logic.
So, my question is: what's the correct way to use each of them?
I am creating a build script so, in my opinion:
tasks should only be what the user is allowed to see, and so, to call through the command line.
By example gradle doSomeInternalTechnicalWork is not correct for me, as the user should even not know that doSomeInternalTechnicalWork exists.
Always in my opinion, it should NOT be a task.
method should be used to organize the build logic, and should NOT be visible by the user
With the former logic, I encounter problems when my methods need to call Gradle tasks (like the JAR creation of the Java plugin).
I know that I should not call task from task (and so the same for task from method), but, have a look to this example:
task independentTask << {
// initialization stuff
println "doing a lot of initialization"
// using methods to organize build logic, good or not?
doComplexThingsThatTheUserShouldNeverDoHimself()
}
task dependentTask(dependsOn: 'independentTask') << {
println "now that 'independentTask' is done, I can continue to do complex things..."
}
void doComplexThingsThatTheUserShouldNeverDoHimself() {
println "doing really complex things"
// I really need to create my JAR here and not somewhere else
// And I know it's not a good thing to directly call the Action.execute
jar.execute()
println "doing other really complex things"
}
In this case, what would be a correct build logic?
Should doComplexThingsThatTheUserShouldNeverDoHimself be converted in 1 or more tasks, so as to be able to dependsOn the JAR task?
But that would mean to have really a lot of tasks, callable by the user, when, indeed, that should not be the case.

Answer 1

After having search quite a lot, I concluded that, when you need to call a task from another task, you have little choice but to rely on tasks relationships (dependsOn, mustRunAfter, finalizedBy).
Which means that methods can't be used to organize the build logic in the same way that they are used to structure a program in Java, Groovy & Co.
As a consequence, you can't prevent the user from seeing (and using) some internal tasks, that should normally only be used as dependency by some other ones.
A "Gradle correct" version of the former build script would hence be:
task dependentTask(dependsOn: 'doComplexThingsThatTheUserShouldNeverDoHimselfPart2') << {
println "now that 'independentTask' is done, I can continue to do complex things..."
}
task doComplexThingsThatTheUserShouldNeverDoHimselfPart2(dependsOn: ['doComplexThingsThatTheUserShouldNeverDoHimselfPart1', 'jar']) << {
println "doing other really complex things"
}
task doComplexThingsThatTheUserShouldNeverDoHimselfPart1(dependsOn: 'independentTask') << {
println "doing really complex things"
}
task independentTask << {
// initialization stuff
println "doing a lot of initialization"
}
Or, with tasks relationships declared separately:
task dependentTask << {
println "now that 'independentTask' is done, I can continue to do complex things..."
}
task independentTask << {
// initialization stuff
println "doing a lot of initialization"
}
task doComplexThingsThatTheUserShouldNeverDoHimselfPart1 << {
println "doing really complex things"
}
task doComplexThingsThatTheUserShouldNeverDoHimselfPart2 << {
println "doing other really complex things"
}
// we declare all tasks relationships separately
dependenTask.dependsOn doComplexThingsThatTheUserShouldNeverDoHimselfPart2
doComplexThingsThatTheUserShouldNeverDoHimselfPart2 dependsOn doComplexThingsThatTheUserShouldNeverDoHimselfPart1, jar
doComplexThingsThatTheUserShouldNeverDoHimselfPart1 dependsOn independentTask
Personally, I prefer the last one, the relationship block being more readable.