On 3 Feb 2014, at 9:33 pm, Radim Kubacki <radim.kuba...@gradleware.com> wrote:
> Hi, > > I'm looking for some ideas on > https://github.com/gradle/gradle/blob/master/design-docs/ide-integration.md#ide-hides-implementation-tasks > & 2nd part of > https://github.com/gradle/gradle/blob/master/design-docs/ide-integration.md#feature---tooling-api-parity-with-command-line-for-task-visualisation-and-execution > describing how to tell important task from implementation pieces. > > 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
