Maven: The Definitive Guide

My one true nerdy tendency: I like writing technical documentation. It's ironic then (or a bit of a hypocrisy) that I loathe reading it. Chalk it up to my lack of passion for technology. I am a passionate problem solver; technology is a sometimes rewarding, sometimes frustrating means to help effectively get the problem solving job done.

Recently, I began reading Maven: The Definitive Guide while getting a pedicure at my local salon (laugh it up guys, I can guess where most of you do your leisure reading). I strongly recommend that any developer approaching Maven for the first (or tenth) time give chapters 3 through 8 a read. This guide is what you hope most technical guides or books would be, but then usually quite early on, they disappoint.

The guide starts with a quick, understandable introduction to Maven terminology and concepts, via a short step by step example. As I was reading this from a "make this worth my while" perspective, I had specific use case questions that immediately popped into my head ... and then, I was pleasantly surprised to find the answers in the next few paragraphs.

For example, the guide mentions early on that "support for transitive dependencies is one of Maven's most powerful features". To that my questions were "What about conflicts in dependency hierarchies?" and "What about compile time dependencies that I don't want to package?". The rest of the chapter addresses exactly those questions with explanations on dependency exclusions and scoping. Finally. A book that thinks like I do :)

A quick summary of the rest of the meat of the guide: chapters 4 through 8 build on the core concepts introduced in 3, with bite size chunks of additional functional explanation in each chapter. The material is presented as a hands on example, building in feature complexity little by little. Chapter 4 shows you how to add new dependencies to your project; 5 introduces simple web application features; chapters 6 and 7 cover multi-module project and enterprise project features. This presentation worked for me on a few different levels:

1. The graduated approach to the introduction of new materials made a large amount of Maven terminology, concepts and finally usage documentation digestible.
2. The authors take great care in describing WHY they arrange and refactor the projects as they do, in a very modular fashion. This approach, in practice, lends itself not only to Maven's default conventions, but also to best practices for software project layout. Note that this introduced complexity to the examples that wasn't necessary to explain the features at hand. But the authors bit that bullet in order to present a good and useful way of developing a project.
   
3. The example projects described in the guide are immediately relevant for me. I write Java code. I use Spring. I use Hibernate. This, of course, will not be the case for every reader, but it was a nice bonus for me.
   

So after all of my monologue thoughts, I leave you with a few tids:

• Read the guide (at least Part 1), then decide how problematic you perceive Maven to be. I know my perception changed dramatically.
• Note that it is a bit outdated, deprecated goals and such (the guide is updated for Maven 2.0.10, I downloaded Maven 2.1). This really didn't distract me at all.
• The chapters I reference are only the tip of the iceberg. Part 2 of the guide includes another 200 reference pages that I have yet to use. I'll let you know how that goes for me:)
  

Because I've Got Issues ...

I have to hand it to the guys over at Atlassian, JIRA is a pretty killer app (although I know now that Love is the REAL Killer App:) ).

I've worked with JIRA for, well, a really long time. I've always worked in companies where you needed to wear many hats, and I'm one of those developers that doesn't get snobby when I'm asked to step outside of my comfy Java home and help out the IT folks. So it's usually me that gets those prize winning projects like migrating forums, internationalizing wikis, or looking for new software to streamline our internal processes. I've spun JIRA around the dance floor several times, XSLT'ing crazy aggregate reports from XML backup formats, writing plugins to support externalizing JIRA data, customizing schemes, changing workflows. Every time, the same epiphany gets me - JIRA just works, exactly how you would think it should.

While some who are not so in the know might think, "Gretchen, you simpleton, it's a series of instructions to a processor, of course that's how it works". But those of us who bend software over and around daily know that few apps are actually written with quality, exceptional exception handling and in an intuitive manner that doesn't require years of higher learning and great tolerance for pain to adopt. (This is a very familiar concept particularly for those who use a certain unreasonable operating system).

This time, we need to move Mondrian's tracker issues from their original home on Sourceforge over to JIRA, which is our tool of choice for managing work and issues at Pentaho. With an assist from my other favorite killer app, Kettle, it has been a dreamy couple of days putting together the pieces to get Mondrian's issues to their new home. OK, maybe not dreamy, but certainly pain free.

Kudos, my Atlassian friends. You Aussies got it going on.