Maven reality TV shows

Tim O’Brien wrote on twitter:

We’re starting a reality TV shows to judge Maven plugins, “Maven’s Worst Documented Plugin” I’m playing the part of a cranky Simon Cowell.

And this got me thinking about reality TV show names and concepts based on existing reality TV shows.

If you are not technical, and don’t know what Maven is: it is what we Java developers use to build software. It is like a workmate: great tool, but every time (once in two years) you want to use it to do a project, you cut your fingers unfolding the workmate (at least I do). Maven is similar in that every time you want to do something different than what you are currently doing, it will cut your fingers. Suffice it to say I have a love/hate relationship with workmates (and Maven).

The list of TV shows I figure will be great hits among Java developers (and Rubyists wanting to make fun of Java developers):

Hardcore pom, based on Hardcore pawn, will feature Jason van Zyl in a shop called Maven Central where project leads stand in line having to argue with Jason about the contents of their pom’s to get them in the central repository.

Keeping up with the Plugins, loosely based on the ‘reality’ soap family the Kardashians, will show the lives of Maven plugin maintainers living under one roof and watch them striving to win the coveted 3 +1′s for their release votes. See their ups and downs as they run the integration tests to prove backwards compatibility.

O’Brien’s Maven Nightmares well known author of Maven books, Tim O’Brien visits Java shops that are on the verge of collapse, analyses what is wrong with the build, pulls out some corpses from the build closets and drills the Java developers with proper Maven procedures. Once he has left the team with a working, pristine Maven build, O’Brien returns 3 months later to see how they have done so far. Viewer discretion is advised due to strong language.

The Fear Reactor, where 4 developers face the dread of all Maven builds: a multi-module reactor build. In each of 3 rounds a developer will be eliminated. The first round is performing some task on a multi module build under time pressure. The developer with the slowest time is eliminated. The second round involves finding an error in a reactor build by having to wade through Maven’s output using mvn –debug level output. The third and final round involves determining what the hell one of the Maven plugins does based on just their documentation (no one has ever passed this round).

Let me know on twitter if you come up with other reality TV shows based on Maven (or Java or C# or Scala or …) Use hashtag #realityshowsincode

Maven-eclipse-plugin woes fixed

There is quite some anti-mavenism going around, about plugins suddenly not working, etc. And often this is true, case in point: maven-eclipse-plugin version 2.6 botched all projects working with Wicket by being very anal about what should live in the src/main/java directory tree (only Java files! God forbid you’d like to put web resources such as .properties (i18n for your web components), .js, .css, .html, etc next to your Java files. This version not only broke Wicket projects, but AspectJ as well.

Fortunately, the Maven community (more specifically Barrie Treloar and Arnaud Heritier) were helpful in finding the root cause of our pain: a conflict in merging the resources paths during the classpath generation.

With the latest snapshot of maven-eclipse-plugin 2.7 we now have our old build stability back, and can enjoy the new features of the maven-eclipse-plugin, such as searching your workspace for projects that are snapshot dependencies, and adding a project link instead of a jar dependency.

Yes, maven can sometimes be a pain, but ultimately with a great supporting and responsive community it will deliver. Many thanks to Barrie and Arnaud for being patient with us.

Downloading the internet with Maven in a new light

I have my share of complaints like everybody else about Apache Maven and one of them is that upon installation (or upgrading to a new plugin version) it starts downloading half of the available internet. Maven is constructed in a highly modular fashion, requiring lots of different, small, focused Java libraries. I’d like the distribution to contain those libraries, but I digress. Tonight I saw that not only Maven is structured this way. It is something *all* open source projects got.

For example, the much touted Ruby on Rails project with their disdain for everything Java would probably cringe at Maven (it uses XML after all). But installing Ruby on Rails and for example Radiant CMS with some plugins is a futile attempt in finding the right invocations of: script/*, rake, gem, port and other commandline tools you’ll want to get familiar with. All these tools start downloading stuff from the internet from different repositories (SVN, ruby forge, etc).

Maven: you’re not alone anymore in downloading the internet for your builds…

m2eclipse is useless

I’ve installed Subversive as my Eclipse subversion connector, and don’t like Subclipse for one bit (having to update after a commit is weird for a workflow). The decision of m2eclipse to hardcode a dependency on Subclipse baffles me. Now nobody is able to use m2eclipse with git, cvs or any other SCM. This renders the m2eclipse support complete and utterly useless. Fail.

Life’s like a box of chocolates: maven 2.0.5 released

It seems that around Valentine’s day and carnival the Java open source community is very generous with sending gifts to the general public: first Wicket 1.2.5 saw the light, and now we can reap the benefits of months of ploughing through issues by the Maven team.

The Maven project released the long awaited Maven 2.0.5. Congratulations and celebrations.