Geertjan's Blog

  • July 17, 2012

Gradle Classpath Support in NetBeans

Geertjan Wielenga
Product Manager

This may be my greatest achievement as a NetBeans Platform programmer, ever. Since my girlfriend is not a programmer, she's not going to be able to join with me in celebrating this happy news. (Well, she can celebrate, but without full appreciation.)

So I turn to the on-line community of developers everywhere: I've created a Gradle project type for NetBeans IDE, with classpath support. That means that not only the JDK, but also the dependencies declared in the Gradle build file are on the classpath of the project:

The JARs in the Libraries node above are defined in the Gradle build file, refer to the screenshot in yesterday's blog entry for details. Those JARs are put on the classpath, thanks to the NetBeans plugin, and can then be coded against, as you can see above.

Still a lot needs to be done before this is usable. Changes in the Gradle build file need to be reflected in the hierarchies in the explorer view; the user should be able to map Gradle tasks to project commands; the user should be able to change the JDK; and many other similar project-level features need to be implemented, while it would also be cool to have the Package View support integrated into this project type.

But, for now, this is a great step forward. It would be great to have a few people out there who'd like to try out this early (and also later) version of the plugin, but bear in mind that only very few features work. Well, you can run all your tasks and the classpath works, so that's all the basic stuff ready to be used by anyone using Gradle.

A small cool thing I like is the fact that the project node hierarchy is pluggable. So, you could create an external module and provide a new node in the project view above, but more about that another time. 

Many thanks to the Grails project (which owes some gratitude to the Ruby project, among others), which is where almost all of the Gradle classpath code comes from. 

Join the discussion

Comments ( 12 )
  • swpalmer Tuesday, July 17, 2012


    I wish I had the time to help :-( I really want to see this plugin become a standard part of NetBeans.

  • slawekmikula Tuesday, July 17, 2012

    Great that the plugin is moving that fast. I hope You can finish it in a nice package ready to use. How about gradle configuration for maven'ized netbeans rcp applications ?

  • swpalmer Tuesday, July 17, 2012

    Just noticed that the bundled Gradle is 1.0-milestone-6. The official 1.0 release version has been out for a while now - and scripts written for it are NOT compatible with pre-milestone-9 versions. You should update the dependencies.

  • guest Wednesday, July 18, 2012

    Sounds great, I need to try it out!

    I love the video, she plays great. And I see that she also plays with big names such as Candy Dulfer!

  • guest Wednesday, July 18, 2012

    Yupi :). Please Oracle don't let it die

  • Geertjan Wednesday, July 18, 2012

    Don't let what die? How can Oracle let my Gradle plugin die? It is an open source project, so if it does then that is your fault, for not contributing to it. That's the flip side of open source: the responsibility of not letting something die is 100% yours.

  • swpalmer Wednesday, July 18, 2012

    "if it does [die] then that is your fault..."

    100% wrong.

    PLEASE don't expect somebody else to finish what you've started. This is the fallacy of Open Source - BLAME THE USERS.

    It is NOT the community's responsibility to finish the work you started. If you can't do it on your own and you want the community to help, that is not unreasonable. But expecting the USER community to do the work without coordination and organization from a project leader is not practical. We want this plugin and those of us with the skill and time to contribute might very well do so. But like yourself, we all have constraints on our time. Do you have time to fix the bugs or add the features you want to ALL of the software you like to use?

    Before you can hand something over to the community you need to build a critical mass of contributors. At the least, the project needs a leader. Do not put the responsibility of *development* on the *users* that have not volunteered for that job. You need to build the community of developers (of this project) or at least one person that chooses to take on the responsibility, before you can hand it over - or it will die.

    What would it take for this to become an official feature of NetBeans - supported by the NetBeans team, funded by Oracle?

  • Geertjan Wednesday, July 18, 2012

    Wait a minute, I'm actively developing this and am not handing it over to anybody. You sound a bit mad -- where did I say I'm handing this or anything else over?

    And what it will take for this to become part of the official NetBeans distribution is quite a lot of analysis to understand the place of Gradle within the other priorities that NetBeans has going forward.

  • swpalmer Wednesday, July 18, 2012

    Sorry.. my tone doesn't come across well in text :-)

    I am very appreciative of your efforts in this area (I said so above).

    But what I didn't like (and was a *little* "mad" about) was your statement that it would be our fault (the community's) if it died. You basically stated that if you stop actively developing it tomorrow, then we are 100% to blame for it dying. Unless you made plans to hand it over before you stopped working on it (something more than simply making the source code publicly available), surely some of the blame would be yours. A project would need fostering in this early stage if it were to survive, and as the project's creator, that responsibility would be yours.

    The "mad" tone was from this assumption by the OpenSource community that it's someone else's fault when bugs don't get fixed, or projects fail. Speaking in general terms about OpenSource: Making your source code available does not resolve you of any responsibility.

    That said, I hope none of that happens. I would like to see this plugin gain some traction and mature into a core NetBeans feature. I hope you can attract some other developers to help make that happen. After having been torture by the awkwardness of working in XML with Ant, and the basic dysfunctional mess that is Maven, Gradle looks to be very promising.

    Good luck!

  • Geertjan Wednesday, July 18, 2012

    My understanding of open source is that it belongs to everyone. But it's not a free ride. You get from it as much as you give. If you're going to be using the Gradle plugin for NetBeans without ever planning to contribute back to it then, yes, you're partly to blame if it dies, since you could have contributed to it but didn't. The extent to which you didn't determines the extent of your blame.

    However, at this point I have a choice between debating with you about the meanining, rights, and duties relating to open source, on the one hand, versus working on the Gradle plugin, on the other hand. I.e., I'd prefer to continue coding, rather than debating. Here ends this entire debate, at least, as far as my participation in it goes because I want to work on the plugin now.

  • swpalmer Wednesday, July 18, 2012

    Well, I agree that is the right choice :-)

    You've changed from me (or rather 'guest') being 100% responsible to being "partly to blame" - so I'm happier now anyway :-)

    I look forward to following your progress, and I will test it when I can - that's all I'm able to help at the moment.

  • Reginald Carey Tuesday, March 19, 2013


    I wish you much success in this. The implementation on IDE 7.3 unfortunately fails a basic smoke test for groovy code :-(.

    package neat

    import static java.lang.Math.*

    import java.awt.Graphics2D

    import java.awt.geom.AffineTransform



    * @author ReginaldCarey


    class Environment implements Drawable {

    In the above code block, the IDE is "unable to resolve java.lang.Math, java.awt.Graphics2D, jaava.awt.geom.AffineTransform and Drawable (which is defined in the same package as Drawable.java)

    Further, my subprojects refuse to show "Source Packages" in the Projects tab. I had to add main/groovy to the folder set of the generated projects and then I had to change the build.gradle to apply plugin: 'groovy' to get anything to compile.

    I'm new to gradle so I had to dig quite a bit to figure out how to get back to the simple "project" dependency model that traditional netbeans projects provide.

    I think that gradle and/or ivy are a great step in the right direction for netbeans and this plug-in fills a gap left by the ivy support that seems to have fallen by the wayside.

    Do you have any suggestions for my above woes? I hope my comments help to steer further enhancement to this plugin.

    Reggie Carey

    former Sun Java Ambassador

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.