Attila Kelemen

Thank you for the catch. The code is not thread-safe. Although it cannot cause a bug because currently this method and the close() are never called concurrently (they are always from NbGradleProject.PROJECT_PROCESSOR which is single threaded). Anyway, this should be fixed.

Next time please file an issue instead because I might not notice here.

Anyway, if you are wondering why I didn't use a simple lock instead: No real reason, just for fun. I like to play with concurrency and I thought there is not much to lose if I screw it here (as I sadly did). Obviously, I should have been more careful.

Thank you for the catch. The code is not thread-safe. Although it cannot cause a bug because currently this method and the close() are never called concurrently (they are always from NbGradleProject.PROJECT_PROCESSOR which is single threaded). Anyway, this should be fixed.

Next time please file an issue instead because I might not notice here.

Anyway, if you are wondering why I didn't use a simple lock instead: No real reason, just for fun. I like to play with concurrency and I thought there is not much to lose if I screw it here (as I sadly did). Obviously, I should have been more careful.

Thank you for the article. I would like to respond to the request:

1. I'm not exactly sure what you mean but 1.1.7 will support customization of built-in tasks. I believe this should solve most issues.
2. Do you mean like it is done for Maven or Ant projects?
3. If the plugin does not list a folder which exists and is configured in the build, then it is not supplied by the Tooling API of Gradle (assuming no bugs). You have to configure the "idea" plugin within the build script, so that the plugin can see the source root.
   
4. I don't know what project type you mean but I'm not planning to add more specialized project types (since they are somewhat tedious to add with questionable value). However, sometime in the future I plan to add somekind of project type which is customizable by the user. However, I have not yet determined the exact way it will be done.
5. The project is never reloaded automatically because it may take quite a bit of time for large projects and you don't always need to reload a project just because you edited the build script (i.e., you need to reload to see the newly added dependencies and source roots, otherwise it is not necessary). Also, editing the build file does not cover all cases when a project needs to be reloaded and in general, it is not possible to determine when the project needs to be reloaded. Perhaps in the future I will consider adding automatic reloading as an optional (opt-in) feature.

Thank you for the article. It is nice to see that the Gradle plugin is being used for something that it was not explicitly planned for. Anyway, I would like to answer to the wishes related to the Gradle plugin:

• Open the browser when running a project...: Opening the browser is simple to implement but with what starting page should it be opened with? And on what condition should the browser be opened (e.g.: when running "jettyRun" task)? (not in the latest release (1.1.4) yet but in the current master branch: the plugin makes lines containing URLs a link to that URL opening the external browser).
• Enable version control when right-clicking a project...: It was already added in the latest version of the plugin.
• Automatically build a project on saving...: It is an interesting problem. The plugin currently relies on gradle for every task it does (build, run, etc.). I'm not confident enough to compile a single file bypassing Gradle, so if automatic compilation is implemented, I would do it by simply starting "classes" task in the background. It might worth a try if it is efficient enough to be useful. Since the daemon is rather quick in incremental compilation once already up and running, it might be possible.
• Glassfish embedded tasks...: It is already possible to define and execute custom tasks for the plugin, so if you have a Gradle task, you can add it to the project's pop-up. Probably, I should add a manual/tutorial for the plugin.

If you have checked the plugin, you are encouraged to dowload it again from https://github.com/downloads/kelemen/netbeans-gradle-project/org-netbeans-gradle-project.nbm.

It is now possible to set the installation directory of Gradle and setting it greatly increases performance. You can set it on the Tools/Options/Miscellaneous/Gradle panel. Also it is now possible to open projects not having a "build.gradle" (by opening their parent and opening them from there).

It means, that when the project is opened, the tooling api of Gradle will make sure, that every dependency is available locally (sources, test dependencies, etc.) and will also load every project which is part of the multi project build even if it is not a dependency of the project (this is necessary for Gradle, since any project may modify any project in a multi project build). That is, when I request Gradle to parse the project it returns everything to me in one step. It will not execute any tasks when opening the project, it is just slow compared to opening a Maven project. However I implemented a simple optimization: since Gradle loads every project of a multi project build, I will cache the parsed project, so opening other project of that particualry multi project build will be an instant. Also, reloading a project, automatically reloads every project of the multi project build.

Building, executing tasks, etc. takes exactly as much time as if you were executing it manually (with the Gradle daemon).

You may try it and see for yourself if the performance is adequate. For convenience, I have shared the compiled NetBeans module as well: https://github.com/downloads/kelemen/netbeans-gradle-project/org-netbeans-gradle-project.nbm

It means, that when the project is opened, the tooling api of Gradle will make sure, that every dependency is available locally (sources, test dependencies, etc.) and will also load every project which is part of the multi project build even if it is not a dependency of the project (this is necessary for Gradle, since any project may modify any project in a multi project build). That is, when I request Gradle to parse the project it returns everything to me in one step. It will not execute any tasks when opening the project, it is just slow compared to opening a Maven project. However I implemented a simple optimization: since Gradle loads every project of a multi project build, I will cache the parsed project, so opening other project of that particualry multi project build will be an instant. Also, reloading a project, automatically reloads every project of the multi project build.

Building, executing tasks, etc. takes exactly as much time as if you were executing it manually (with the Gradle daemon).

You may try it and see for yourself if the performance is adequate. For convenience, I have shared the compiled NetBeans module as well: https://github.com/downloads/kelemen/netbeans-gradle-project/org-netbeans-gradle-project.nbm