Maven: when it works, it really works. When it doesnt, it really sucks.

About a week ago, we decided to fix our build. Because of architectural and implementation changes, the build, which was fairly monolithic, was no longer capable of deploying our components, which (a) had interdependencies, (b) depended on a lot of 3rd party jars, and (c) were, as the term implies, modular and not monolithic.

One of the senior devs on the team suggested that we switch from Ant to Maven2. As the original writer of the Ant script that was used to build the first paltry web server that launched the demo that got the project rolling, I wasn’t an Ant expert, and basically punted dependencies, relying on build order and installing all jars to the same dist directory that was on the classpath. When better Ant wranglers came along, they parameterized everything and made it work good enough, which was actually good enough until last week.

Still, I’m wary of overengineering (because I’m so damn good at it :), and maven2 seemed like a case study in complexity. The learning curve was steep — especially in the middle of an integration, when I’d rather be coding than reading about POMs. And, unlike my mac, you can’t just pick up Maven and run with it. You need to understand about repositories, both for resolving dependencies and uploading compiled components.

I almost cracked, when, in the middle of a yak shaving exercise involving a bash script and a recalcitrant database, something went sideways with a POM file and I had to start all over. But then I remembered that Gil, the guy who wanted to use Maven, was lazy — lazy in a good way. He would never sign up to work any harder than he absolutely had to, because he wanted to have time to learn more cool things. There had to be something to this maven crap, other than the clever and witty blog posts.

My turning point came today. I created a new project, I needed to whip up a servlet, so I created a webapp from a maven archetype and ripped off some old servlet code from somewhere, and jammed it in to the right place according to the maven directory layout. Then I added some lines to download the Jetty plugin, did some reading, and figured out that I could run jetty as a maven task in a way that detected changes in my class files and automatically re-deployed my app. Then I looked up a way to debug from eclipse, which almost made me not miss Ruby as much, because my code-debug cycle was pretty much automated. No more code-deploy-debug-redeploy, it was just code-debug-code-debug, (and by code, you TDD nazis, I mean write tests first and make them pass, of course!!

In the end, I have mixed feelings about Maven. When you get over the learning hump — and I do remember having similar learning humps with ant and make — it takes a lot of the cruft of build management out. When something goes wrong, it can be really hard to figure out how to resolve the issue — for instance when a necessary plugin isn’t specified in the almighty POM, you only get a message saying that the plugin isn’t there, not one to check your POM. And some of the documentation does leave something to be desired. Still, now that I’m seeing the light at the end of the tunnel — and I had Gil to set up repositories and lend a helping hand — I do feel like in the end it’s a net win when your project changes from ‘toy’ mode to ‘production’ mode.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: