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 usingslf4j
, I used dependency exclusion to get rid of the hardwired logging framework and used aslf4j-log4j
bridge instead so I could ultimately log tologback
. - 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:
- Use it to get rid of things that break your build
- Get rid of things that you're replacing with something else
- 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.