Sunday, November 21, 2010

Does technology still matter?

This week the Java conference W-JAX 2010 was held in Munich and I had the pleasure to talk about some Maven Magic. The JAX conference series is quite popular here in Germany. I've been attending it more or less regularly over the last years. Like probably most other developer conferences all over the world, the sessions at JAX and W-JAX typically cover the current "hype-technologies". I enjoyed the conference very much and learned some news about JDK 7 and 8, garbage collector tuning and distributed versions control systems.

But, and this is a notable difference to all the conferences before, two of the keynotes had nothing to do at all with new technologies. Instead, the speakers (Nico Josuttis and Gernot Starke) talked a lot about the "soft" side of IT. Basically they asked themselves and the audience: Does technology still matter? This is surely a challenging question for a conference packed with developers. Nonetheless, both talks were excellent and made me think again about how to handle "all-new" technologies in my job.

The baseline of these thoughts is: I'm sure technology matters, but I'm not sure, how much. In large projects, the fraction of project staff that are actually IT-experts is amazingly low. You'll find a lot managers, business analysts (which are experts, too, of course, but not driven by technology) and, to be honest, a lot of developers that are, well, not experts. This is even more true if you look at projects that have entered the maintenance phase of their life cycle.

This is not a new discovery, of course. But do we really take this fact into account when designing and implementing new systems and technologies? I try to, but the problem is, I like technology. Its so much more fun using a brand-new technology for a given problem than an old, boring (but proven) one. And I know most other experts out there feel the same. That's why they talk on conferences about JDK 7 and 8, about the pros and cons of closures and, like me, the magic of maven dependency management.

Over the last couple of years and right now during the keynotes on W-JAX I got the feeling that this attitude to concentrate on technology details somehow is, yes, irrelevant. Its cool for us, the developers that spend their spare time reading blogs. But, as Nico Josuttis said in his keynote: "The war of experts in IT is lost". IT is a mainstream technology today. It's expected to be reliable, efficient, affordable, stable - but not cool. And it's expected, that all those technologies are manageable by non-experts. The people that drive the current technologies in new directions should keep this in mind. Is a discussion, what's the right way to incorporate closures in JDK 8 appropriate from this point of view? Certainly not. Is a discussion on how to consequently make Java easier to understand for non-experts (like the Groovy guys did) appropriate? In my opinion, certainly yes.

Friday, November 5, 2010

NetBeans 7.0 M2 and Maven 3 - Better than M2Eclipse?

I've been and am still a happy user of Eclipse since V1.0 - but there is always room for improvement, even in the best tool. And, honestly, the Maven integration is certainly one of the weak spots of Eclipse. M2Eclipse offers a lot of functionality in this area, but it is SLOW. I tried all sorts of tricks to speed things up (some of them I described in this post), but still: it is slow. It is not that slow that one cannot work with it. It is just slow enough to put me in anger from time to time. For example, Eclipse gets sometimes completely stuck. Or it takes several minutes to perform a simple refresh operation. Nothing critical, but anything from smooth ...
I talked to a colleague a while ago and he pointed me to the new M2 of NetBeans 7.0. He told me that it comes with an improved integration of the brand new Maven 3.0. I never used NetBeans before, but the issues with M2Eclipse bother me enough to take a look at it. Here we go:

I freshly installed NetBeans and opened my Maven project. No need for some sort of special import here. I simply choosed File | Open Project and selected the project folder containing the Maven root project. NetBeans even marks all Maven projects in the tree with a special icon.

The import finished amazingly fast. NetBeans analyzed the project structure for while after the import in a background process, but nevertheless I could immediately start to work with my modules.

After the background processes finished, some problems showed up in the project list. NetBeans marks the respective projects with warning and error icons. In the context menu of a project you can click on "Show and resolve problems ..." to open a summary of all problems.

In my case Maven could not find some dependencies in my local repo, which is OK (I did some cleaning up the days before and obviously I was little bit to rigorous). Additionally I was only kind-of online during the tests.

Next, I took a look at the folder structure inside one of the modules. Obviously, NetBeans knows a lot more about Maven projects than Eclipse/M2Eclipse. For example, it knows about generated-sources right out-of-the-box. Even more important, it knows that Maven maintains separate dependencies (and classpaths) for "normal" modules and for tests.

The latter one is in my eyes really important. The Eclipse builders don't distinguish between classpaths for modules and for module tests - regardless if you use Maven/M2Eclipse or not. In consequence, you will regularly run into issues where the Eclipse builder runs flawless, but the Maven build will not. This is just because some of your modules coded in Eclipse reference a dependency with test scope. Eclipse will not recognize this, but Maven will. And NetBeans, too. I like that!

Besides the more or less cosmetic features I was especially interested in how NetBeans performs compared to Eclipse/M2Eclipse. To test this I did some simple refactorings in a central module of one my biggest Maven projects. Since this module is referenced by nearly all other modules, the builder gets a lot of work. In Eclipse this means, that for all dependent modules the M2Eclipse and the internal builder is invoked. This works OK, but again, it is anything from smooth. My first tests in NetBeans have been quite encouraging. First, the refactoring worked nearly as fast as in Eclipse. Second, the build really executed in the background. That is, I was able to continue working during the build. Next, the build completed in seconds, not minutes.

After these basic tests I played with some of the other features. One thing I would like to mention is the dependency graph in NetBeans. It works similar to the one from M2Eclipse, but adds some useful features. For example, it zooms out an artifact and all direct dependents from the graph if you select it (and dims all others). It's hard to explain, but very cool and useful. Try it out yourself!

I also found some features of M2Eclipse that are not supported in NetBeans (at least I didn't find them). There is no such thing as a full-blown POM editor. NetBeans has a POM editor, but it "just" supports editing directly in the XML. The XML editor has a lot of features, like inserting new dependencies using an artifact search. This is perfect for me, since I never used the comprehensive M2Eclipse editors, but I know many people do.

Summary: I am quite impressed about how well-integrated NetBeans 7M2 and Maven 3 are. Both the functionality and especially the performance are in my opinion better than what you currently get with Eclipse and M2Eclipse. But please keep in mind that this only reflects my experiences of a first try. Certainly, if I start working with NetBeans more intense, more problems will arise. And, of course, a new release of M2Eclipse will be out soon, maybe this fixes many of the current issues. But still: I think NetBeans 7 is well worth a try for all developers that rely on Maven as a build system.