On Wed, Oct 24, 2012 at 10:53 AM, Hans Dockter <[email protected]>wrote:
> Attila has send me the following email about what he thinks is important > for good Netbeans integration and IDE integration in general. In agreement > with him, I'm forwarding this to the dev list. See my comment below: > > On Sun, Oct 21, 2012 at 12:16 AM, Kelemen Attila < > [email protected]> wrote: > >> I will write down my needs as you asked. Although there some of my >> requests scattered on the forums and in JIRA, I will try to write down each >> of them here. You may forward this to your devlist or wherever you see fit. >> >> 1. Cancellation in the Tooling API. This seems to be the most important >> to me. Without cancellation, I can't even cancel a "run" or "debug" task >> and finding the started task in the process list is not always easy. >> > > Absolutely. > > >> >> 2. Event notification through the Tooling API. In particular, I would >> like to be notified when a task waits for a debugger to attach. Currently I >> attach to the process by parsing the stdout of Gradle and waiting for the >> string "Listening for transport dt_socket at address". This is kind of an >> ugly solution. >> >> 3. On a developer a machine the daemon could eat up a lot of memory and >> there seems to be no limit how many daemons can spawn. I have tried to >> decrease the problem by writing the plugin so, that it does not execute >> tasks concurrently (including loading of projects) unless for certain kind >> of tasks (run, debug). However, if the user starts two tasks with >> incompatible JVM arguments, there will be two daemons running and the >> processes will remain even after they are going idle. Do this a few times >> and you can effectively kill any pc. So my proposal is that at most only >> one idle daemon might run concurrently. If there are more, one must commit >> suicide. >> > > You are talking about tasks from different Gradle builds? > This is the reply from Attila: To clarify the 3rd point: It might be due to using multiple versions of Gradle but more likely it is because you started two gradle builds with incompatible jvm arguments; or simply, executed two builds in parallel (I expect one of the daemon to die when both builds complete). Executing two builds in parallel is something that is likely to happen when executing a "run" task (i.e.: you need to execute multiple apps in parallel). > > >> >> 4. There is this issue: http://issues.gradle.org/browse/GRADLE-2495. If >> it is not fixed in 1.3, then I have no reason to update to 1.3, this bug is >> *very* annoying. >> >> 5. Currently for large multi-project builds, loading the project takes a >> long time. It would be nice if it was not neccassary to load each project >> of a multi-project build. I have written about this on the forums: >> http://forums.gradle.org/gradle/topics/lazy_build_script_evaluation. I >> was told that you are planning to make changes toward this (and other) >> goal. >> > > Absolutely. There are few ways we will tackle this problem. > > >> The only thing I would add here is that, the one I stated in the forum is >> the most important thing to me in these changes. Also, I prefer changes >> where I can write a script now and without changes it would also work with >> later versions of Gradle. If it is not the case, it could annoy users >> because if they work on projects built by different versions of Gradle they >> have to change the path to Gradle before opening projects. Or perhaps, I >> could ask the Tooling API to find the version of Gradle needed for the >> project (if so, allow me to set that I need the sources of Gradle as well >> or not). >> > > The usual Gradle build use the wrapper which specifies a version which is > considered by the Tooling API. > > >> >> 6. If scripts were reading input from the stdin (adding convenient >> support in Gradle could help) and this bug was fixed: >> http://issues.gradle.org/browse/GRADLE-2462, then users could execute >> tasks which require an input from the user. For example, a >> "createSubproject" task. I have written such tasks at the company I work >> for, so that others new to Gradle can easily create new projects. >> >> > Good point. > > >> 7. There is one last thing with the Tooling API. Instead of having >> EclipseProject, IdeaProject or similar, it would be benefical to have a >> view of the project which is more native to Gradle. In fact, I think >> maintaining EclipseProject and IdeaProject is a waste of effort. If you >> could create only one model, which more native to Gradle, one could >> transform it different model as he/she wishes. Writing a method which >> converts the native view could be measured in hours but if you do this in >> the Tooling API, it takes a much larger effort because you need to consider >> backward (or worse, forward) compatibilty. Here is an example model: >> https://github.com/kelemen/gradle-model-example. Note that I only spent >> a few hours creating this (including the apidoc), so it is likely in a need >> for some adjustment. As a last word for this issue, I think you should mark >> the current models deprecated and create a model which contains more >> information and is more close to how Gradle sees the world. >> > > Interesting point. I'm curious on what the others have to say here. > > Hans > > -- > Hans Dockter > Founder, Gradle > http://www.gradle.org, http://twitter.com/gradleware > CEO, Gradleware - Gradle Training, Support, Consulting > http://www.gradleware.com > > > >> >> Attila Kelemen >> > >
