So in my  previous post  I explained how to simplify your logging with Maven and SLF4J. If you haven't read it yet, please do before reading more.  Since then I've discovered an easier and cleaner way to remove the secondary frameworks from your Maven dependency tree. Here's a revised overview of the steps: Decided which logging framework will be your primary, aka who will actually write to your log file. Define the dependency scope of all the secondary frameworks to be ' provided '. Configure your project to depend on drop-in replacements of each secondary framework from SLF4J. Define secondary frameworks as provided Use the dependencyManagement section for this. Its used when you might have a dependency transitively. Add dependency on SLF4J Add the following to your pom.xml Conclusion So now in only 3 steps you can redirect all your logging to your primary logging framework without changing a line of code!

I realized today that I had made this nice flowchart about two years ago of how I decide when to add qualifiers and increment version numbers, but I never shared it anywhere very useful. This is heavily based on the version numbering scheme that Maven inherently understands. You should also checkout the excellent versions plugin for Maven that include some great utilities for upgrading your plugins and dependencies.

UPDATE: Ceki commented below which prompted me to rewrite the third paragraph. UPDATE 2: I have a better way of configuring Maven and SLF4J now. The mismatch between logging frameworks always seems to come up in projects I've developed over the years. Little-by-little I've learned and relearned how to navigate the nest of runtime logging that occurs in non-trivial applications. With my latest project I think I finally converged on a solution that I'll carry forward to future projects. So what am I really talking about? Have you ever been stumped, even for a short time, about where a certain log message is going and why it might not appear in your log? Often this happens when you are trying to debug an issue with a third-party library that's using a different logging implementation them your application. If you are nodding from familiarity, skip the next paragraph. Let's start from the beginning. There are several logging implementations available for Java, th...

Recently I came across a company that is forking several open source Java projects. I saw they were making a mistake that I also made a few years ago and have since learned from. In Maven's distributed repository architecture project artifacts, like JAR files, are uniquely identified by a coordinate system composed of a group identifier, an artifact identifier, a version number, optionally a classifier, and a packaging type. For instance, the most recent version of the Apache Commons Lang project has a Maven coordinate (i.e. groupId:artifactId:version:classifier:type ) of commons-lang:commons-lang:2.5::jar . A few years ago, if I wanted to make custom changes to this project I would get the source, make my changes and then deploy the result to our private Nexus repository under a new groupId such as com.jaxzin.oss:commons-lang:2.5::jar . That might seem reasonable. Then a year later or so I tried something different and changed the artifactId like this commons-lang:commons-lang-jax...

Recently I've been helping a colleague introduce a dependency on a legacy project that hasn't been "Maven-ized". Often the "easy way" to add a legacy dependency is to throw the JAR into our Nexus repository and be done with it. But this legacy project was a little trickier and is my new poster child for why taking the easy way can lead to headaches and frustration. Your legacy project might have compile-time dependencies you need. Maybe your legacy project implements an external API, or maybe it uses a library and exposes that usage in its API. "So what", you say? "I'll find it at compile-time for my project and I'll add the dependency." Well, now every project that wants to use your legacy project is going to go through the same discovery and embed the dependency in their POM. The right way is to define this dependency in the pom.xml for your legacy project so all dependent projects retrieve it transitively. Your legacy pro...

So try this in Maven. Create a project A and don't install it. Create two subprojects, B and C, that have A as their parent. Make B depend on C. Install C. Try to build B. You won't be able to as Maven claims it can't download A. Huh? Why did C build then? The cause is that Maven can resolve a project's parent on the local drive using a relative path. But if a project has a dependency, it will only look up that dependency's parent through the repositories, even if that parent is available via a relative path. The solution, install A into your local repository. If another developer gets B out of your SCM and tries to build they will fail with the same problem. So I've now learned. Deploy more snapshot builds of parent POMs to keep my fellow developers happy.

My coworker asked me to describe how Maven compares and differs to Ant. I realized how hard it was for me to describe what a developer gets for moving their build process from Ant scripts to Maven. I can't make the argument that you can do X with Maven but not with Ant because I don't really have a valid example. However, I am inclined to make the argument that you can do X with both but with Maven it's easier. With Maven, you collect metadata about your project instead of writing scripts defining the steps your build will take. For example, if you look at an Ant script you'll immediately see that it is organized as targets which many developers use to define and group the steps of their build process. In a Maven POM file, you won't see similar build steps defined. This can be confusing for a new Maven user coming from the world of Ant. I know it was for me. Instead, you'll see lots of metadata about the project such as dependencies, Maven plugins to use...