On 12/09/2011, at 6:54 AM, Payne wrote: > Hi, > > > during last few days I was part of NetBeans Platform training and as a > evenings result we have implemented some super alpha version of Gradle > support. > > Right now we are able to add Gradle build file for web and standard > application. Some basic stuff are already implemented and right now it is > project and will be published on java.net as open source. The fact is we > need to get more requirements what the plugin should support and what is > missing. > > You can read more information at: > http://blogs.oracle.com/geertjan/entry/gradle_in_netbeans > http://blogs.oracle.com/geertjan/entry/gradle_in_netbeans_part_2
This is excellent stuff. > > The stuff right now is how can we really improve the Tooling API we are > using right now to get more features out of the box. We do not really want > to be forced to parse the DSL... And we really don't want you to have to. We'd like all interaction between the IDE and Gradle to happen through the tooling API, if we can manage it. We put quite a bit of effort into making sure that the tooling API is backwards and forwards compatible, to shield people writing integrations from changes in the DSL. Plus the tooling API gives us some opportunities to improve performance that you wouldn't get if you bolted directly onto the DSL (we haven't really taken advantage of this so far, but intend to). So, if you need to do something that you can't at the moment, we can certainly add stuff to the tooling API. What stuff would you like to see on the API? We've almost certainly have not got the API right, either, so if there's stuff that's awkward to do at the moment, we can probably make changes to simplify it. > > I also want to ask why in the tooling API are interfaces with prefix > Eclipse? The thing is they are not really tight to Eclipse projects This is because we started with Eclipse integration, and exposed only the stuff the STS team needed to do this (well, really it's a small subset of what they need, but we had to start somewhere). So the interfaces are all targeted at Eclipse, and expose the Eclipse view of the Gradle model. We've since added a basic IDEA model: http://gradle.org/releases/latest/docs/javadoc/org/gradle/tooling/model/idea/package-summary.html And we've started fleshing out a generic Gradle model, which is agnostic of IDE: http://gradle.org/releases/latest/docs/javadoc/org/gradle/tooling/model/package-summary.html You might find it better to use the generic model for NetBeans integration, rather than the Eclipse model. At some point, we might add a NetBeans-specific model to the API. For example, the NetBeans model might expose all the projects in a Gradle build as a NetBeans project group. Or it might expose separate test compile and test runtime classpaths for the project. > . I also > want to ask what can we improve from Gradle perspective in terms of NetBeans > support? Something like generating project templates, ... I guess there are a few broad areas that IDE integration should cover at some point: * Allow me to import an existing Gradle build into the IDE, and have everything configured so that I can run tests, run the application, and so on. * Allow me to see and run arbitrary Gradle tasks from the build. * Help me visualise and manage the dependencies of the build. * Synchronise changes made in the IDE and the build scripts, so I can make changes in the IDE and have them reflected in the build scripts, and vice versa. * Help me write build scripts, with syntax highlighting, code completion, documentation lookup and so on. * Help me bootstrap a new Gradle project. * Help me migrate a project to Gradle. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
