The training started well, when Matt mentioned that he thinks deleting a line of code improves the code you are working on. I totally agree and always found refactoring sessions that remove reams of code especially satisfying.

Manfred then goes on to list his impressions of Maven 201, including the points that really stuck out for him.

It is amazing how much you can theoretically configure the build with profiles and then lock things down with plugin/dependency management and the enforcer plugin – for heavy regulated environments or tight requirements this is ideal.

To follow Manfred’s experiences throughout his Maven training courses, go to his blog.

• Dependency management doesn’t select the highest version

A misconception that I’ve often heard is that “Maven chooses the highest version” when two or more transitive dependencies disagree on the version of a given groupId and ArtifactId coordinate.

It may surprise you to learn that Maven’s dependency resolution process is a rather simple one.  This simplicity is actually a benefit for the sake of debugging and manually resolving the dependencies.

The fact is that Maven resolves the version nearest to the top of the dependency tree.  But how can you visualize this hierarchy?  There are two approaches.

The first approach is via the command line and the dependency plugin.  At the prompt in a Maven project, type:

mvn dependency:tree

You receive an ASCII art rendering of the dependencies, including transitive dependencies.  Now it is relatively easy to see what is closest to the top.

But an even better visualization comes from the m2eclipse plugin.  Open Eclipse and choose File->Import->Maven->Existing Maven Projects

Once the project is imported, double click on the pom.xml file and then choose the Dependency Hierarchy tab.  And you get an even richer representation of the dependency tree.  The m2eclipse plugin offers “conflicted” and “from” hints in the version descriptions of each tree node above and beyond what the more simplistic command line implementation offered.

Now that you’ve visualized what version will be automatically selected (nearest to the top of the tree) by the resolution process, we can discuss in the next blog post what the best approaches and anti-patterns are for controlling third party library versions with just a few simple tags.

In the upcoming posts, we’ll discuss more Maven revelations such as:

• Integration tests have their own lifecycle
• Parent references do not have to be symmetrical with module references
• Dependency management is a better option than exclusions to control versions of transitive dependencies

These topics often turn into complete discussions given the dynamic nature and flexibility of our Maven course offerings.  If you’d like training from “The Maven Company” to get best practices, proper techniques, and time saving approaches to working with Maven, take a look at our Maven 101 and 201 public offerings in an instructor-led web training format.