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:)