Douglas has posted 1 posts at DZone. View Full User Profile

Why I Like Using Gradle in NetBeans IDE (Part 2)

11.05.2012
| 5801 views |
  • submit to reddit

Part 1 of the NetBeans/Gradle series came from Martin Steffen in Uruguay. Below, in part 2, we travel to Scotland!


 

My name is Douglas Maxwell. I’m Scottish and  a Java software consultant specializing in financial apps. 

I’ve been using Groovy for over a year now and that is what led me to start experimenting with Gradle. I enjoy the terseness and expressiveness of the Groovy language, which I am able to exploit for build management with Gradle, no more XML verbosity and the ability to exploit Ivy’s excellent dependency management.

I manage my own software codebase in Subversion. I develop using agile methods which means lots of unit and integration tests. The codebase is managed with Gradle and the CI jobs are executed on a Jenkins server. I prefer to develop in NetBeans IDE using Gradle to manage my projects primarily because of the excellent support for dependency management and the ease of use when configuring multi-project builds.

What follows is a short description of a basic server side module for trade capture and my typical development workflow:

  1. Go to Tools | Plugins in NetBeans IDE 7.2 and install the Gradle plugin. Then open or create a Gradle Java project in NetBeans IDE, using the Open Project dialog or New Project dialog to do so.
  2. Write code and configure dependencies in the Gradle "build" file:



    This project consists of some service and DAO classes.  It uses Spring JavaConfig and JPA to manage persistence. The database is sql server 2012 in spite of the fact that I am a big fan of Oracle 11g. There is a single integration test which runs a Groovy script to set up the database schema and inject the initial test data. Here is the build file.



    As you can see it uses artifacts from a local Ivy repository. The output from the build is deployed to the same repository.
  3. I run all the test locally:





  4. The changes are then committed to the Subversion repository. Currently I do this external to NetBeans IDE, though I think this can be done from the IDE with the latest version of the plugin.


  5. As this project is not part of my main build, I have setup a separate gradle job in Jenkins,  which runs when changes are detected in the Subversion repository.




Conclusion

I am very impressed with the NetBeans plugin for Gradle so far. Rarely do I have to step out of NetBeans IDE and run a part of the build from the Gradle command line. I would, however, like to see some of these features added:
  1. the ability to add command line switches when a task is executed
  2. the ability to navigate test results in the Projects window
  3. the ability to add Groovy sources
  4. the ability to create different types of Gradle projects with the appropriate plugins and dependencies added automatically
  5. the ability to have a project update automatically when changes are applied to the build file.

The last feature might be implemented but it just doesn’t seem to work for me!

Published at DZone with permission of its author, Douglas Maxwell.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Attila Kelemen replied on Tue, 2012/11/06 - 5:49pm

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.

Matt Coleman replied on Wed, 2013/02/06 - 12:58am in response to: Attila Kelemen

a valid point Attila!

sell sheet design 

Bryan Low replied on Thu, 2013/03/07 - 10:15pm

I have always believed that investments in Hillview Peak condo and condominiums is always a better choice than any other forms of investment. Not only can the investor leverage on his investment, he can always stay in the unit should he decide not to rent out the unit. Investing in stocks, gold etc has really no tangible benefits on your investment. Thats just my 2 cents thought though. Thank you author for the informative writeup.

Hillview Peak

Morkel Abie replied on Fri, 2013/04/12 - 6:16am

This blog is always wonderful..the insights are too brilliant and useful .Thanks for this good site. bigger erection

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.