Maven exclude philosophy

Question

• What maven Excluded dependencies was invented for?
• Should I care to exclude any dependencies other then for fixing libraries conflicts?
• What would good maven project architecture look like:
  • tend to exclude as much as possible
  • or as minimum as needed?

Answer 1

I don't know the reasons for the design but I've seen it used in the following cases:

• I had a library which had junit as a compile time dependency so JUnit code leaked into my production code.
• I had a library which uses log4j. Since I'm using slf4j, I used dependency exclusion to get rid of the hardwired logging framework and used a slf4j-log4j bridge instead so I could ultimately log to logback.
• In another case, I was using only some features of a framework and didn't need all the dependencies. Since they weren't optional in the first place, I used exclusions to keep my classpath lean and clean.

General rules:

1. Use it to get rid of things that break your build
2. Get rid of things that you're replacing with something else
3. Get rid of things that you know you don't need (optional)

If none of the rules apply, leave the dependency alone; chances are that the immediate dependency might change over time and suddenly, it will need some dependency that seemed superfluous before and you code will unexpectedly break.

Answer 2

In addition to Aaron's answer:

An exclusion is usually needed when the provider of the dependency did something wrong (i.e. did not make a dependency optional where he should have, included an actual logging backend - as opposed to api - or used the wrong scope).

The one exception is logging frameworks. See Aaron's answer for that.

So no, do only exclude dependencies if you have a specific reason to exclude them.