I am using the managed API (V3) for task creation by a custom plugin. So there will be the same additional set of tasks for each declared component. I would like to influence the hierarchical presentation of tasks.
Example
Just as your ‘visual-studio’ plugin does, the tasks ‘subtree_xxx_foo’ and ‘subtree_xxx_bar’ will be generated for say ‘A’, ‘B’ and ‘C’.
public static createTasks(ModelMap<Task> tasks, GitSubtreeDomain args) {
args.getSubtrees().forEach { sub ->
tasks.create("subtree_${sub.getDisplayName()}_foo") {
/* doLast something ... */
}
tasks.create("subtree_${sub.getDisplayName()}_bar") {
/* doLast something ... */
}
}
}
The given (small) example would produce
'subtree_A_foo'
'subtree_B_foo'
'subtree_C_foo'
'subtree_A_bar'
'subtree_B_bar'
'subtree_C_bar'
Problem:
I would like to influence the hierarchical presentation of tasks. I found different ways to influence that tree represetation, but none works consistently across all 3 mainstream tools: ‘gradle --gui’, Eclipse BuildShip, IntelliJ IDEA.
1. ‘gradle --gui’
‘gradle --gui’ visually represents the subproject relation as defined by include statements in settings.gradle files, e.g.
// file: settings.gradle in root folder
include "folderA", "folderB"
and
// file: settings.gradle in folderB
include "folderC"
as a nested tree structure. Very nice, I like that best. It allows me to influence the graphical tree structure by carefully placing plugin applications into separate build.gradle files organized via nested settings.gradle hiearchies. If I select a task under a project node other than the root project node, it will execute that task in the context of the root project (to be precise: in the context of the project that I opened as root when invoking ‘gradle --gui’)
–> intuitive, flexible, clean.
2. IntelliJ IDEA
IntelliJ IDEA represents all nodes of the project hierarchy as a flattened list, each node with classification subnodes of task classifications ‘build’, ‘application’, ‘documentation’, ‘ide’ , ‘other’, …
That classification scheme could be useful, if you documented how to annotate tasks with classifications. But currently everything is added to ‘other’, and that folder explodes in number of children when expanded at the root project level. There it accumulates all tasks of all subprojects. If I open a project node other than the root project node, the tree lists only the tasks of that specific project, fair enough, but it will only execute its listed tasks in their sub-project scope, not in the context of the root project.
3. Eclipse Buildship
Eclipse seems to have a similar graphical representation but I cannot confirm for sure that its semantics regarding contexts and scopes are the same as in IntelliJ, since I currently use IntelliJ’s more mature Gradle tooling.
Suggestion
Please find a consistent logic for graphical tree representation across different IDE/GUI tools so that we can design build file structure carefully to offer everyone the same selectability/executability of tasks with same context semantics, independent of IDE or Gradle GUI in use. A common component in SWING/JavaFX reused across all IDE plugins and ‘gradle --gui’ will synergize “community efforts” and provide a consistent user experience.
A Unique Selling Proposition of Gradle is its headless build and IDE independence. Currently that is not achieved regarding execution of tasks. And execution of tasks is the core feature of Gradle. If a team works with Eclipse, someone else will have problems to use the build files in the same manner for a different tool: IntelliJ IDEA, or Sublime + Gradle GUI, or KDevelop + Gradle GUI, Emacs + Gradle GUI, Notepad++ + Gradle GUI. But if I am bound to a single IDE choice for all collaborators, there will be less motivation for Gradle as a headless build tool.