NetBeans 6.8 and Maven – The Perfect Combination

There have been quite a  things that have endeared me to post 6.1 versions of Netbeans, the most vital and outstanding reason why we finally settled on NetBeans in our development office was its Maven support. It just works, and I’ll show you why we can’t do without NetBeans 6.8.

First off, I don’t have make any extra effort to specify that I want to open a maven I just click “Open Project”, navigate to the location of checked out project source, and it automatically detects that it’s maven project. That’s when all the magic sets in. And even during out from my Subversion repository, it automatically detects all maven modules and opens them accordingly. No mucking about.

From an open project,  immediately get the normal NetBeans structure of “Source and “Test Packages”. You also get “Libraries” – a list of all dependencies of compile scope , “Runtime Libraries” – list of all those of runtime scope, and “Test Libraries” – for those of test scope. Nicely separated to make it easy to classify your dependencies. What is even more exciting is that transitive dependencies are of a gray colour, and the brighter coloured jar
files are the direct compile dependencies (as you can see from xstream.jar and xpp3_min.jar in the picture). So you know if that jar file causing annoying ClassLoader exceptions was not actually added by you directly, but by a dependency you specified. Saved me quite some hours, this colour coding.

To add dependencies is quite easy, both by directly editing the pom.xml file, or by right-clicking any of the appropriate “Libraries” folders, from the menu of many other useful actions, clicking “Add Dependency” and doing a search using either the groupId or artifactId. The code completion provided when directly editing the pom is spot on, and
adding by using the wizard couldn’t be easier. It’s even intelligent enough to automatically set the selected scope to “runtime” when you right-click the “Runtime Libraries”. Clicking the appropriate version of the artifact automatically populates the rest of the fields for you, and with the “Ok” button, you are done. Interestingly, beside the artifact details are the indication whether this artifact is to be downloaded from some repository, or available
in your local .m2/repository folder. This is possible because it indexes your local repository, as well as remotely configured ones, which in my case is our local Nexus mirror tagged “central”.

Having added all your dependencies, you can then generate a dependency graph, which can be very useful in understanding where all the artifacts you find in your resultant build come from. Just right-click any of the “Libraries”
nodes (or the module itself), and select “Show Dependency Graph”. Interestingly, you can just right-click a particular dependency, and get it’s own dependency graph. Moving your mouse pointer over a dependency in the graph immediately shows you details on the artifact i.e. groupId, artfactId, version, scope and type. If you have a
million and one dependencies like we do in our project, the “Find” at the top of the graph is very helpful in digging out the particular dependency you are interested in without having to wade through that minefield.

Whenever your project becomes a multi module one, you can easily create a parent project. Then use NetBeans to move your existing module under the newly created parent folder in your file system. Netbeans will recognise
this immediately (provided the packaging of the newly created parent one is “pom”) and will edit the parent pom with a new module declaration.

But what about when you reference a class which is not available in your classpath whiles coding? Well, along other suggestions that the IDE gives you, one is the suggestion to look in your Maven Repositories. You then get a list of artifacts that match the class you have just referenced. Selecting the right version of the one you want and clicking “Add” automatically adds this artifact to your pom as a compile scope dependency. Could life be any easier than this?

Even NetBeans’s “Search” which appears on the right hand corner can be used to search through your maven repositories and automatically download an artifact. Sweet.

Also, Netbeans has a Maven Repositories tab, which shows you a searchable index of both your local repository as well as other repositories that come already pre-configure. You can add a new repository, search through existing
ones, and update your local index of these repositories. When you find a dependency of interest under any node of these repositories, just right-click and select “Copy”. Go to your pom file and under the dependencies declaration, right-click and paste. A new <dependency/> declaration is pasted here with the appropriate groupId, artifactId and the rest. Smart.

If your project makes use of profiles, activating them during a build is so easy. Just click the drop-down menu on the toolbar, next to the “Build” toolbar item, and your profiles are available. This is very useful to me when I’m switching between running test cases and just building the code without executing tests.

And, all of this is very flexible. In every project’s properties, there’s the opportunity to make all the changes you want, like changing what goal, properties and profiles are activated when you “Build” or “Clean and Build” a module. Whenever I add a dependency that is not available in my local repository, the module is highlighted with a suggestion
icon. Right-clicking the module, you get “Show and Resolve Problems”, which enables you to force the download of the
dependencies declared without waiting to build using maven itself. Also if your module is a web module that need to run in a server, it prompts you on the need to specify the appropriate server.

Interestingly, unless you make a lot of changes to the way your maven modules are built, NetBeans hardly ever creates any IDE specific files, and your project is virtually clean when you commit your changes back to your source control. This is not quite the case for IDEs like IntelliJ (which takes a very long time in reading and detecting the modules of your maven project on the first open of the project) and Eclipse.

The availability of the settings.xml and profiles.xml (if defined) for direct editing in the IDE provides a truly integrated experience. In some cases where I’m having issues with my local Nexus mirror, I’m able to just comment out the Nexus mirror defined in the settings.xml and download my artifacts directly from the internet. I don’t have to go looking for
my .m2 folder in my file system to make this change.

What strikes me most is the fact that every other integration that NetBeans provides works. When working with JPA, entities are automatically detected and I get the usual suggestions for mapping etc. If it’s a Spring project, all
my bean mapping files easily resolve their references. There’s nothing which the IDE provides already that I loose by my project being a maven project. Name it. Facelets, SVN, auto-redeploy when I make changes to a web project. Everything that’s supposed to work does indeed work.

And, no matter how different your build is from maven’s convention over configuration settings, NetBeans has not failed in being able to read all my modules and building my multi module project perfectly. I’ve had very frustrating experiences with M2Eclipse, especially their WTP support. It just hasn’t worked for us, though I never had any issues when I checked opened the same project with NetBeans (at least not since the last time I checked, which was last week with the 0.10 version of M2Eclipse).

So although I miss a lot of things like using Richfaces VPE for facelets editing in Eclipse, I think I’ll rather hand code my facelets with the excellent facelets code assist from 6.8 of NetBeans, just so when I’m finished and I click “Run”, it indeed runs without a hitch.

The only problem I have with this maven support in NetBeans is the attempt sometimes todownload sources when I’ve never specified that sources should be downloaded alongside the artifacts. But, that’s few and far between,
and I can absolutely live with that.

I’ve been meaning to say this for a while, and now finally I’ve got the chance to do so. NetBeans with Maven just rocks. I look forward to even cooler features and improved support in NetBeans 6.9.


RichFaces plugin Released for NetBeans 6.1

< Seam PDF Rendering

Last week Geertjan Wielanga released a plugin he’d been working on for RichFaces tag support in NetBeans. I gave it a shot and its not bad.

Its meant to provide tag support as well as drag and drop of RichFaces controls on the palette. Interestingly this support is meant for both jsps and facelets. But seriously speaking, how many people are using RichFaces on jsps instead of on Facelets? Since this plugin only works with NetBeans 6.1 and the facelets support plugin does not work with 6.1, I really wonder what use it is to me and to a significant number of others.

This is really causing me to worry for Sun. Anyone doing anything new in JSF is not going with JSPs if they really know what is best for them, but rather with Facelets. If Sun really wants JSF to catch up (alongside using NetBeans as their preferred JSF development tool) then they should provide us developers with at least some of what JBoss Tools provides – visual editing. I’ve been waiting for Sun’s Visual JSF to now support Facelets, cos there’s no way I’m sticking with Rave. I think a lot of people share this sentiment and it is the reason why everyone is praising Seam for the good work its doing.

If Sun has seen it fit to bring Jacob Hookom onto the JSF 2 EG as a sign of respect for what Facelets stands for, then it should stop sitting on the sidewalk with Facelets support in NetBeans and get some decent support for it (and I mean not just tag support). Most of us NetBeans fans are in a love hate relationship with it because of such political (in)decisions. Sun should continue taking developers seriously and see how to improve on it’s technologies with already proven ones instead of trying to stuff things down our throats that we don’t want to swallow.

28th May 2008

Ah. I just came across a release of the Facelets support for NetBeans 6.0 rebuilt to work with NetBeans 6.1. Good job by Here is the download. And thanks to Po-Ting Wu for the rebuild instructions.

Thanks also to Geertjan for the work on Richfaces support. JSF development will get better and easier!

Fedora 8 and NetBeans Problems

Last month i got a hold of Fedora 8 and upgraded my 7 installation. I’d heard about the IcedTea version of the JDK already installed in Fedora, so I decided to go ahead and install without updating to JDK 6. Much to my surprise, NetBeans won’t install with the following error

‘Assertion ‘c->xlib.lock’ failed.’ error.

and a lot more.

Changing to JDK 6 didn’t help either. NetBeans is the IDE, and not being able to use it outta the box just drove me nuts. In a hurry to use my system, i just re-installed Fedora 7 and went back to life as usual.

However, to all the folks who had also tried to install NetBeans 6 on Fedora, here is the solution to a problem that turns out to be from the JDK itself.

For sun-java5-bin:
sed -i ‘s/XINERAMA/FAKEEXTN/g’ /usr/lib/jvm/java-1.5.0-sun-

For sun-java6-bin:
sed -i ‘s/XINERAMA/FAKEEXTN/g’ /usr/lib/jvm/java-6-sun-

Got it from here

Also for those of us who want NetBeans to work alongside the XGL destop effects, here’s the workaround

put into the script file of NetBeans this line: export AWT_TOOLKIT=MToolkit

Here’s the source

Now let the Fedora 8 games begin