Gradle Classpath Support in NetBeans

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. 

Comments:

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

Posted by swpalmer on July 17, 2012 at 08:35 AM PDT #

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 ?

Posted by slawekmikula on July 17, 2012 at 11:50 AM PDT #

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.

Posted by swpalmer on July 17, 2012 at 01:48 PM PDT #

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!

Posted by guest on July 18, 2012 at 12:30 AM PDT #

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

Posted by guest on July 18, 2012 at 01:25 AM PDT #

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.

Posted by Geertjan on July 18, 2012 at 01:28 AM PDT #

"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?

Posted by swpalmer on July 18, 2012 at 06:19 AM PDT #

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.

Posted by Geertjan on July 18, 2012 at 06:43 AM PDT #

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!

Posted by swpalmer on July 18, 2012 at 08:52 AM PDT #

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.

Posted by Geertjan on July 18, 2012 at 09:08 AM PDT #

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.

Posted by swpalmer on July 18, 2012 at 12:13 PM PDT #

Geertjan,

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

Posted by Reginald Carey on March 19, 2013 at 03:18 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
12
13
14
23
24
25
26
27
28
29
30
   
       
Today