How to tell important tasks from implementation details

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to tell important tasks from implementation details

Radim Kubacki
Hi,


I agree that if a task has non empty group attribute then it is a signal that it should be important enough. I don't understand the other part 'any task that is declared as a public task of a build element'. If build element == BuildableElement then the only class implementing it is GradleProject and I guess we don't want to change behavior of GradleProject.getTask() to return subset of current results. Or what else is build element in this context?

Now the question is how to make this available in Tooling API. We can add GradleTask#getGroup().
I like using task's group attribute because it is more powerful than say using description attribute or filtering based on some naming convention (for example ignoring tasks starting with '-'). It allows to filter some tasks (w/o group) and group the rest into tree-like view. The problem is that this is an addition to an existing interface. It is expected that this is OK for ToolingAPI users but it can be hard to support this for an older Gradle providers. I think it can be relatively easy to support this for Gradle 1.8+ only. Would it be sufficient?

-Radim
Reply | Threaded
Open this post in threaded view
|

Re: How to tell important tasks from implementation details

Adam Murdoch

On 3 Feb 2014, at 9:33 pm, Radim Kubacki <[hidden email]> wrote:

Hi,


I agree that if a task has non empty group attribute then it is a signal that it should be important enough. I don't understand the other part 'any task that is declared as a public task of a build element'. If build element == BuildableElement then the only class implementing it is GradleProject and I guess we don't want to change behavior of GradleProject.getTask() to return subset of current results. Or what else is build element in this context?

‘Build element’ means subtypes of BuildableModelElement, introduced by the native language plugins. These will also be rolled out to the jvm plugins too. They represent the ‘things’ of a build.


Now the question is how to make this available in Tooling API. We can add GradleTask#getGroup().
I like using task's group attribute because it is more powerful than say using description attribute or filtering based on some naming convention (for example ignoring tasks starting with '-'). It allows to filter some tasks (w/o group) and group the rest into tree-like view. The problem is that this is an addition to an existing interface. It is expected that this is OK for ToolingAPI users but it can be hard to support this for an older Gradle providers. I think it can be relatively easy to support this for Gradle 1.8+ only. Would it be sufficient?

The main point of this work is that the UI should not duplicate the logic that Gradle uses to decide what the entry points are and whether they are public or not. This means that we don’t want the UIs to use a group attribute to decide this. Instead, we want to expose whether the entry point is public or private. We should add a flag that models this - eg a ‘public’ flag or similar.

The flag should be on EntryPoint - every entry point is either public or private.

As far as using this with older providers goes, I think we should do exactly what we do for everything else we don’t know, which is to fail when you ask the question. It would be a separate piece of work to change or improve this pattern, for example to provide some way to ask ‘give me this model with reasonable defaults for the missing pieces’ or ‘tell me if this property is supported’ or whatever.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com