A long time advocate of the open source community, and contributor to the Sonatype’s Maven books, Manfred Moser, recently enrolled in our Maven training courses, and has decided to document and share his experiences. First on tap is Maven 201 with Matthew McCullough.
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.
Over the course of the last several months of teaching the Maven 101 and 201 courses with Sonatype, it has been exciting to hear some of the “aha” moments that students have had. I’d like to discuss some of the most frequently occurring ones in a series of blog posts, starting with the most common epiphany:
- 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: