Odtnhj

I have been reading the Introduction to POM and don't understand the following. In the pom.xml you can configure dependencies, let's say we configure dependency maven-embedder. Then you can exclude a dependencies of your dependency, let's say we want to exclude maven-core from the maven-embedder dependency. In what cases would you like to do that? Wouldn’t that cause your dependency to stop working if it does not have all it dependencies? I’m obviously missing a puzzle piece here :)

 <dependencies>
 <dependency>
 <groupId>org.apache.maven</groupId>
 <artifactId>maven-embedder</artifactId>
 <version>2.0</version>
 <exclusions>
 <exclusion>
 <groupId>org.apache.maven</groupId>
 <artifactId>maven-core</artifactId>
 </exclusion>
 </exclusions>
 </dependency>
 ...
 </dependencies>

Example: https://maven.apache.org/pom.html#Exclusions

Perhaps an example will help. We had a use-case for this recently.

A dependency of ours (which was quite big, but of which we needed just a couple of isolated methods) had a dependency on Rhino, but we wouldn't go anywhere near the Rhino-touching parts of the code.

In our module we were including YUI Compressor. For whatever reason, both libraries feature exactly the same fully qualified class name, but with slightly different method signatures.

The result was that including the transitive dependency of Rhino broke functionality that was previously working. YUI Compressor threw a runtime exception because the method had a different signature than it expected.

The solution was to exclude Rhino explicitly.

In general, you should not have to exclude dependencies. It usually comes as a result of modules which are poorly designed.

For example, if a module becomes too big then most users may only need a fraction of their classes or methods, so not all of their dependencies will strictly be required. In this case, the library designers should probably break the module down into a set of smaller modules.

Having the same fully qualified class name in two different libraries seems like a poor design decision as well.

The trick here is that you might want to use another version of the transitive dependency, not the default one. In another word, you might replace or even disable some default part of behavior.