Gradle 2.1 task visibility and group property

Gradle 2.1 Tooling api has support for tasks visibility public vs internal. Launchable#isPublic() added since 2.1. Javadoc states that task needs to have non-null ‘group’ property. I’ve tried the following: task hello << {

group = “Hello_Group”

println “Hello!” } hello.group = “Hello_Group” hello.description = ‘Say hello.’

However, task ‘hello’ isPublic() still returns false. How do I need to define the task such that isPublic() returns true? How to define the group property correctly?

Try this:

task hello {

group ‘build’

}

I took it from a test for this functionality - https://github.com/gradle/gradle/blob/master/subprojects/tooling-api/src/integTest/groovy/org/gradle/integtests/tooling/r21/TaskVisibilityCrossVersionSpec.groovy

Yes, I found that test from the related commit on the GitHub and tried exactly the same task in Gradle Eclipse integration, but still had visible field set to false. Do I need to apply a special plugin perhaps for this to work? (Eclipse Gradle plugin build model with ModelBuilder#get() method and it builds an EclipseProject Gradle tooling model if i refresh the tasks)

You need to call isPublic on a Launchable instance from BuildInvocations model. Tasks accessed using IdeaModule.getProject().getTasks() and EclipseProject.getGradleProject().getTasks() do not return this property correctly. It would be better to correctly return it or at least throw UnsupportedMethodException to avoid surprises.

Thanks Radim. Indeed when i got BuildInvocations model #isPublic() started to work correctly. One more question. Is it possible to distinguish aggregate (includes tasks from child projects) tasks from current projects tasks with the BuildInvocations model? I noticed that #getProject() method is not working for a Task from BuildInvocations model. In Eclipse Gradle Tasks view aggregate vs project local tasks are displayed (toggle button triggers the filtering). If BuildInvocations model cannot be used for that then I suppose I’d have to fetch EclipseProject model too i suppose.

The reason why getProject() does not work is that we want to keep BuildInvocations model simple just for this purpose: to query for tasks/selectors. If we add project back we would have to transfer whole transitive closure of referenced objects between daemon and tooling API client. It starts from a task to its project and then to all projects and their tasks.

The idea is to use BuildAction where you can get tasks/selectors (selector is what you call aggregated task) for particular project -
http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/BuildController.html#getModel(org.grad…, java.lang.Class)
Your action will run in daemon process and can collect this for projects that are open in IDE and the result will be serialized back. The problem here is that you can get BuildInvocations this way properly for Gradle 1.12+ only. 

ProjectConnection.getModel(BuildInvocations.class) will return model for all Gradle providers including older than 1.12 too but it uses context of root project (or default project I am not sure at the moment). It is implemented for the old versions using some compatibility layer on tooling API consumer side. So I guess you will need to keep your aggregating code in place to support pre-1.12.




Radim fetching the model from Gradle using ProjectConnection.getModel(BuildInvocations.class) takes just about as much time as getting EclipseProject model. It seems to be running all tasks. Is getting BuildInvocations model going to be any faster if I use the BuildAction approach you mentioned in your previous post? It’s for Gradle 1.12 and above runtime, right? Would you be able to provide a code snippet for obtaining BuildInvocations model using a BuildAction if it’s going to be faster? Thanks!

Cheers, Alex

There are few things to consider:

  • Accessing BuildInvocations model from ToolingAPI provider older than 1.12 effectively means to get GradleProject
  • Accessing BuildInvocations for newer versions will show a difference for large builds (hundreds or thousands sub-projects with some levels of nesting). Note that selector is just a project path + task name in this case compared to recursively built task list.
  • We expect that in the future more specialized models will be more effective as the continued work on lazy configuration will allow to perform less operations on daemon startup