Unbridled IDE Anger

It's midnight as I type this. I have spent the past four hours attempting edit a single freaking Grails project within an IDE. Any IDE.

I switched to NetBeans almost nine months ago and I've been a very happy NetBean'er. Everything worked out of the box with minimum futz and complied quite nicely with accepted standards. Maven 2, Subversion, minimalist Java runtimes and Spring hummed along without complaint. Looking to accelerate development of simple maintenance web applications I turned to Grails... and then things started to fall apart.

Grails actually has some great tooling within NetBeans, but one bug has been a huge thorn in my side. An acknowledged bug causes Grails projects to not notice any external libraries, even if they are your own and open within NetBeans. This is beyond annoying because features like syntax highlighting, error detection and auto-completion go completely awry. The bug is reportedly resolved in the upcoming version 7 of NetBeans, however I installed Beta 7 and the problem continues to occur.

Not being beyond switching back to Eclipse, I decided to try Spring's own IDE. Spring's IDE is a slightly customized version of Eclipse, with a bit nicer front-end dashboard for plugins and Spring product support built-in. Since Grails is a Spring project I figured it would work well.... and indeed it did. My other projects... well...

SpringSource Tool Suite uses the latest beta of Maven 3 for dependency resolution... and you cannot change that. Yes, you can specify alternate Maven installations, but STS completely ignores those settings for dependency resolution. Maven 3 will also refuse to load transient dependencies if it doesn't like your POM as well - which means that you simply cannot load your application with all required libraries if your Maven 2 pom.xml is rejected by Maven 3.

I could go back to my old Eclipse installation... and then I need to find a way to load the Grails plugins into the old Eclipse install. That sounds like loads of fun.

So now I have three choices:

1. Use NetBeans and have absolutely no auto-complete or strongly typed variables
   
2. Use SpringSource Tool Suite and re-do all my Maven 2 POMs
   
3. Use my old Eclipse installation and try to install the necessary Spring plugins
   

Now, bear in mind I've burned four hours trying to STS to work. Another four to get NetBeans to work. How interested do you think I am at trying to get MORE plugins shoved into my old Eclipse installation?

I'm cheezed because NetBeans Grails support is rendered nearly useless by a fairly blatant bug. And I'm cheezed because Eclipse continues to be an albatross to every normal project I have. IntelliJ IDEA - you might just be next.

Until then, I've got a Grails app to blindly maintain while NetBeans continues to yell about imports not being found.

Eclipsed by a Bean Maven

I've long been a fan of NetBeans, but for the past several years I have had to use Eclipse. Nearly all of the projects or organizations I've walked into have had pre-existing standards and ways of doin' stuff, and the worst thing you can do as a greenhorn in a company is try to switch horses mid-stream.

Wow... I get a triple combo score for clichés there.

Now I get to bootstrap a development team and decide what we use. The awesome thing is that there are now something like elebenty kabillion IDEs, RIA frameworks and rapid application environments. JSF no longer blows. Everyone uses the same build files now. XML hell is now in the rear-view mirror. Vendor lock-in isn't what it used to be thankfully enough.

When I started building out projects I went for an IDE with tight Maven 2 integration, JSF 2.0 support, Java EE 6 interwoven and nice Subversion tools. I imagined that I'd be heavily leveraging plugins from the Spring IDE project and plugins from JBoss, notably the Drools Workbench. All this plugin support caused me to initially lean towards Eclipse.

As I went further along I also started using GlassFish v3 instead of Tomcat, exploring JavaFX and increasingly using Maven 2 for continuous integration and artifact generation. I didn't really use the features of Spring IDE at all, and while I did use the Drools Workbench I ended up doing more decision-table type stuff, making drl's easier to manage. Ultimately a deciding moment came when I needed to do a very quick-and-dirty desktop application with a simple user interface... something that just needed a logo, URL text field, username and password. For the life of me I couldn't find any free/OSS plugins for Eclipse that let me create a quick JDesktop or Swing application... at least within the 45 minutes that I had available. After pulling out my hair I had a sudden flashback to the good ole' ConsultComm days and reminisced "boy, creating UIs in NetBeans sure was swell." It was at that point when I tried to think of any reasons why I was sticking with Eclilpse... and came up empty.

I've switched to NetBeans, which the IDE itself made extremely easy with it's Eclipse workspace synchronization. Read that line again... synchronization. I know! Mind blowing! It doesn't import the project, it allows your project to remain in the Eclipse workspace while also being mantained in NetBeans. Easy!

All the UI goodness I remembered was still there. In no time flat I had created the entire UI and help menus. Not once did I consult a HowTo or documentation, instead it all immediately made sense. The entire project was done before lunch.

I have shifted all of my development to NetBeans now, despite the fact that I can't be sure where its future lies. I don't care. I'll take advantage of an easy-to-use IDE as long as I possibly can. If I switch back to Eclipse in the future it will like be because I was forced to... just like every other time in the past.

As for standardizing on a development environment: I've learned that no one IDE fits all. Every developer has a preference, and with Maven 2 reaching near-ubiquity it doesn't matter nearly as much as it used to. I say let every developer chose his or her IDE, just pick the one you work most rapidly and naturally within. As long as I can build it with mvn on the command line I just don't care.