Mojo Dev: But did you test it?

The Mojo Project houses non-core Maven plugins. These plugins are not a part of the core Maven 2 release.

Take a look at the project, and you’ll notice that it is too “wide” – there are about 50 released plugins and 30+ sandbox plugins, that are all in various states of disrepair. There are released plugins, like the Maven Cobertura plugin, which have been released in a broken state. And, there are projects that seem to work fine. The issue with Mojo isn’t size per se, it is that no one is really paying much attention to the commits and the vote threads, I’m tempted to just create a fake plugin in the Mojo Sandbox, throw some broken code in there and then call for a vote thread: I’m almost certain I’d get a sufficient number of votes to graduate from the sandbox and cut a release.

Releasing Broken Software

The Coberura plugin is fairly important, it is the alternative to the Clover plugin and it produces unit test coverage reports. While Cobertura isn’t as polished as Clover, it provides a similar report, and (most important) it is free to Clover’s ~$250 per workstation. If you’ve played around with the Cobertura plugin from Mojo, you may have noticed that, it doesn’t work as documented, and even once you get it working, all the classes instrumented have 100% coverage.

Hmmm…so the documentation is wrong, and even once you get it working, it doesn’t really work. So….how did this thing get released? Here are some important emails from the vote thread (from this January and February). First an email to Mojo Dev from Brett Porter on Jan 11:

“I’m seeing complaints that 2.1 doesn’t work. Did all those that voted
test it? Are these isolated incidents, or is there something
fundamentally wrong with the release?”

Followed by an equally important email from Joakim Erdfelt on Jan 12:

“It seems to stem from 1 jirahttp://jira.codehaus.org/browse/MCOBERTURA-57

I missed the vote against 2.1, I would have voted -1 just because of the
above jira.

BTW, I field about 3 direct emails about cobertura-maven-plugin 2.1 a
day now. I recommend that to all people to downgrade to 2.0 for the
time being.

We can probably revert MCOBERTURA-57 and release 2.1.1 as a short term fix.
The long term fix for MCOBERTURA-57 has recently been checked in at the
cobertura (non-plugin) subversion at sourceforge.net

Then, more than a month later, the discussion is concluded with a question from Brett Porter on Feb 24:

Ok, but there were definitely problems aside from that movement hack
– so do we need to nuke 2.1 from the repository?”

Brett’s question was met with a resounding silence.

What is interesting about this whole discussion is that none of the five people who voted +1 on the release bothered to answer the question posed by Brett Porter: “Did all those that voted test it?”. All those +1 votes came within 24h of the original vote email. One can only conclude that no one even bothered to check it out and test it. The people who voted +1 on this particular release probably never even bothered to use the software. If they had given it a try, they probably would have released that the documentation was wrong.

Harmless?

Some developer just giving a knee-jerk +1 on a developer mailing list translates directly into some user getting so frustrated with Maven that they give up. People just voting +1 on a release because it’s Mojo and they can’t be expected to test every plugin release just creates frustrating software.

Gearing up to JavaOne 2007

Off to JavaOne in a few weeks, I’ve got my schedule set, and I’m trying to decide what’s worth paying attention to. Clearly JRuby is something to watch, from the JIRA issues and Subversion commits, it looks like the JRuby team is furiously focused on getting something to call “finished” by the big conference. The things I’m interested in the most are: JRuby, New Language Features, and anything that related to opening up JCP and/or OS licensing.