Both sides have a tool. A library author can mark a dependency optional so consumers do not inherit it. A consumer can add an exclusion to drop a specific transitive dependency. Which to use depends on who is making the call, and the dispute usually starts when each waits for the other.
The two mechanisms
The Maven documentation describes both.
Exclusions. If project X depends on Y, and Y depends on Z, the owner of X can explicitly exclude Z using the exclusion element inside the dependency on Y. This is a consumer decision.
Optional dependencies. The owner of Y can mark Z as optional. When X depends on Y, X depends only on Y and not on Z. The documentation suggests thinking of optional dependencies as excluded by default. X can add Z itself if it needs it.
| Mechanism | Who uses it | Where it is written | Effect |
|---|---|---|---|
| Exclusion | Consumer of a library | Consumer's POM, on the dependency | Removes that artifact from this project's tree |
| Optional | Library author | Library's POM | Stops the artifact from reaching any consumer by default |
Where the dispute starts
A vulnerable component Z sits behind library Y, and Y's code does not need it for most users, maybe because it supports an optional feature.
The app team says Y should have marked it optional. The library team says consumers who do not use that feature can exclude it. Both are using the tools correctly. Nobody has acted.
How to decide
Ask three questions.
- Does the library itself need Z at runtime for its main features? If not, the library team should mark it optional in the next release. That fixes every consumer.
- Does your service use the feature that needs Z? If not, you can exclude Z today, with no wait.
- Is Z needed for a feature some consumers use? Then optional is the right design, and consumers who need it declare it themselves, which also puts the version in their hands.
Exclusion is a local, immediate fix. Optional is a structural fix. Do the first now and ask for the second.
Risks to check before excluding
- Runtime errors. If Y calls Z in some path, removing Z can cause a class loading failure far from the pom. Run tests that touch those paths.
- Another path. Z may arrive through a different dependency too. Check the tree after the change.
- Silent coupling. A later upgrade of Y may start needing Z. Keep a comment and a test that fails loudly.
The Maven guide recommends using the dependency tree and analyze goals to inspect results. Use both before and after.
Write it down
Add a short comment beside every exclusion: the advisory, the reason, the owner, and when to revisit. An exclusion with no reason becomes folklore, and the next engineer is afraid to remove it.
Quick check
Can a consumer remove a transitive dependency without the library team?
Yes. An exclusion in the consumer's POM drops that artifact from the consumer's tree. Test the library's code paths afterwards.
What does optional do for consumers?
It stops the dependency from reaching consumers by default. Consumers who need it declare it themselves.
Sources
Last reviewed: 19 October 2026.
