m2eclipse tip

I was wondering why one of my computers seemed to have an older version of m2eclipse installed. It turns out that they moved the update site from to Doh. It’d be nice if they mentioned that one the front page.



I hate maven. The UI sucks so badly, it’s incredibly painful to use. Anything that can take the edge off this has to be a good thing. In the past, I’ve experimented with m2eclipse, but to be quite frank, it’s not much improvement over the command line. And the tools are why we use Java instead of Perl/Python/Ruby, right?

So now I’m trying out q4e, which is being promoted as the “official” maven integration for Eclipse. At some point. Hopefully.

After installing (0.4.0), first impressions are good. There’s a “new maven project” wizard, which knows about archetypes. Creating archetypes manually is incredibly annoying (I can never remember how). Now, the wizard just lists them for you:

The q4e archetypes wizard

Afterwards, it nicely prompts you for details like groupId and artifactId. Plus a description, which I’d never have thought of otherwise. The more metadata the better! (Actually, the description appears to vanish once the project has been created).

Once created, this is what you end up with.

A new maven project created by q4e

Nice and simple so far. Most of the maven commands are on the right-click menu:

q4e's main menu

When you run something, you get a log viewer, which is a little nicer than the m2eclipse console. At least it’s timestamped.

The q4e log view

Unfortunately, the dependency management appears to be broken. I can’t search for dependencies in the way I could in m2eclipse. That’s not good, as there are lots of them available and the computer should be telling me what the heck they are.

Annoyingly, it seemed to “lose” my src/main/java folder. I had to recreate it in order to get it to work. Very odd.

It will graph dependencies, which is probably more useful on a larger project than my test app.

The q4e dependency viewer

There’s no help yet, which is annoying, though not critical (I don’t know anyone who uses Eclipse help much anyway. Developers—who’d believe it, eh?)

The one thing that’s been really bugging me with maven is the complete inability to get at the source code of dependencies. Oh sure, it’s available for download, and there are features to ask for the source to be downloaded. But I have no idea how on earth to make it work. Not having source code is a real problem when it comes to understanding software.

It didn’t offer much help in the way of creating tests (A default src/test/java would have been nice).

Overall, it’s pretty clear that this is a very early stage of development. But it still looks more promising than m2eclipse, and anything that can make maven easier to use is most welcome.

That was all written last night. This morning, I’ve updated to the development build (0.5.0). It’s managed to grow a “Fetch Source JARs” command, which is great. Unfortunately, I’ve just bumped into issue 153—the compiler settings aren’t synced between maven and eclipse. Oh well. I stand by the previous paragraph. This has potential, but it’s not there yet.



Eclipse’s spelling checker has a WTF moment:

Seriously, what dictionary doesn’t have “thesaurus” in it?


Eclipse Markers

I’m trying to develop a plugin for Eclipse that uses jslint to validate your JavaScript. This involves scanning all the JavaScript code, and using markers to say where the problem lies.

I’ve almost got this done. But there was the slight problem that when I clicked on the problem view, it took me to the beginning of the file (more or less) instead of the line I should have gone to.

After hours of searching, wading through the debugger, etc, I finally managed to figure out what was going on.

  • You can’t set IMarker.LINE_NUMBER and IMarker.CHAR_START together—they’re mutually exclusive.
  • IMarker.CHAR_START and IMarker.CHAR_END refer to offsets from the start of the file, not the start of the line.

Needless to say, this is not documented anywhere. Eclipse is feeling rather programmer-hostile right now.


Emacs vs Eclipse

Steve Yegge has yet another very long, but hugely informative post up: The Pinocchio Problem. It’s all about what makes great software. Or at least, less-bad software.

One of the things he touches on is Emacs and Eclipse extensions, when compared to Firefox.

The very best plug-in systems are powerful enough to build the entire application in its own plug-in system. This has been the core philosophy behind both Emacs and Eclipse.

Recently (the last 6 months), I’ve been doing almost exclusively Java work, and pretty much exclusively in Eclipse. Before that, I was a die hard Emacs user. Why switch? Well, trying to develop Java code without the help of an IDE is like pulling teeth, basically. Eclipse is an astonishing piece of software, but I’d hesitate to call it “good”. Least-bad is a far better moniker.

But I’m really concerned about the extensions. In Emacs, when you want to extend it, you have to write some lisp code. It sounds scary, but Emacs goes out of its way to make this as easy as possible. Whenever you ask for help on a keystroke, there’s a little link to the source code. You can quickly learn how something works by reading the code for how similar things work. Then, when it comes to actually writing some code, Emacs has a handy interactive mode where you can type code in, run it and see what it does. It’s a real pleasure to use.

Eclipse, being based on Java, goes out of it’s way to make your life difficult. When you want to write an add-on, there is no simple way to see the source code for any of the existing bits. First you have to create a plugin-project. Then diddle the classpath to see which bits of Eclipse you want to extend (Which bits do you need? It’s probably documented on the vast and rambling website somewhere).

Then it’s code writing time. Eclipse tries very hard to make Java palatable by compiling as you type. But it’s still ugly. And what code to write? Well, the “New plugin project” wizard probably made you some examples, if what you were doing was close enough to one of the seven or eight things that the authors thought of.

And how do you run this code you’ve written? Fire up a second copy of eclipse, along with a new workspace. Yes, that’s right, another several hundred Mb of memory just to test-run an extension. Genius, folks. Sheer genius.

Not that this situation has me annoyed at all. I even bought a book to try and understand the process (side note: what is it with all the frames, eclipse people? Pay a designer already). I got about a third of the way through before realising that I wasn’t prepared to even contemplate the herculean effort involved in writing plugins.

The whole experience has left me realising quite how powerful Emacs is. Sure it has it’s flaws (no lexical variables in elisp), but it’s just so much easier to use than Eclipse, it’s scary.


Remote Eclipse Debugging

This article on Configuring Eclipse for Remote Debugging is very useful. Java debugging is really nice, because of the protocol for debugging a remote JVM. The first time I managed to debug a servlet in Eclipse, I was astonished.

Hang in there with the article. Most of it is irrelevant if you’ve used Eclipse at all before. Look for the heading Configuring a Remote Debugging Configuration in Eclipse, that’s where the useful bits start.



I tried running subclipse a little while ago when I first started looking at Eclipse. I couldn’t make it work. It would just hang on commit. However, this morning, I ran the automatic update in Eclipse and noticed that a new version of subclipse was available (0.9.27). I upgraded, and tried it out.

And it works, beautifully! Full subversion integration inside Eclipse. It’s lovely! Although by now I’ve gotten used to ow the CVS integration works, so it feels a little clunky to have to use the SVN Browsing perspective instead of simply saying “new project; checkout from cvs.” But that’s a minor quibble.