Hierarchical Presentation and Classification of Tasks across 'gradle --gui' and Eclipse and IntelliJ

Help/Discuss
1

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.

2

I think the issue here is that the gradle --gui doesn’t take the task group into consideration, whereas IDEA and Buildship do. If you don’t specify a value for group then by default it gets listed under “Other”. I’d suggest simply assigning all these tasks to reasonable groups.

3

right on! The concept of grouping looks like a convenient alternative to the current behaviour of ‘gradle --gui’. As you recommended I just tried

tasks.create("subtree_${sub.getDisplayName()}_foo") { 
  group 'subtree'
  doLast {  /* ... */  }
}

and IntelliJ will list it under that additional folder ‘subtree’ - as promised. Thank you!

remaining issue 1
To achieve the clarity of ‘gradle --gui’, I tried to declare a multi-level hierarchy. With hierarchical namespaces of group labels, the user could freely design his hierarchy of gradle.settings and build.gradle files, independent of the intended graphical tree representation of tasks. I defined task groups

'subtree.a', 'subtree.b', 'subtree/a', 'subtree/b', 'subtree:a', 'subtree:b'

and IntelliJ actually listed all group folder nodes flat as children under the Tasks node, e.g.:

Tasks
+-- application
+-- ...
+-- subtree.a
+-- subtree.b

I expected:

Tasks
+-- application
+-- ...
+-- subtree
    +-- a
    +-- b

How can I define a multi-level hierarchy? Is there a namespace format for group?

remaining issue 2
Will you provide a consistent behaviour for ‘gradle --gui’ and the other IDE plugins?

With the current versions, your recommendation will not work without IntelliJ/Eclipse, e.g. for Sublime users, MSVS users, KDevelop users, Emacs users, Jenkins administrators, …, who run ‘gradle --gui’.

4

No, groups are single level.

To be honest, the Gradle gui hasn’t been touched in some time and is unlikely to change. As for IDE integration we do manage the Buildship project but as for IntelliJ that is handled by the JetBrains folks.

5

I am looking forward to your Buildship improvements. If you ensure its model interpretation does not depend on any EMF pre-processing and its graphical representation introduces no SWT dependencies, the Gradle community can reuse it in the standalone ‘gradle --gui’ to keep logic and representation consistent across tools. When some party decided to provide a tool as a Gradle plugin instead of creating a proprietary GUI / scripting interface, they could invest some of their saved efforts into the common Gradle front-end.

BTW clear and honest communication, just as in your model configuration talks on YouTube. Thank you, Mark!