Maven Dependency Hell Teil 2

Folgender Fall, ich benötige a.jar die ist abhängig von b.jar. Aber b.jar ist wieder abhängig von c.jar. Dies führt oft dazu, dass ein Maven Projekt viele JARs benötigt, die es in der Realität nicht braucht, denn es ist nicht notwendiger Weise so, dass a.jar auch c.jar braucht. Dafür bietet Maven eine passende Konfigurationsmöglichkeit. Hier dies mal konkret für das Problem der Bibliothek jide-oss und dem Archiv aqua.jar. Noch ein Tipp, schaut euch mal im Eclipce Depedency View an welche Archive Log4J im Schlepptau hat.

<dependency>

<groupId>com.jidesoft<groupId>

<artifactId>jide-oss<artifactId>

<version>2.8.4<version>

<exclusions>

<exclusion>

<artifactId>aqua<artifactId>

<groupId>aqua<groupId>

 </exclusion>

 </exclusions>

</dependency>

Hier stellt sich wieder die Frage, ob convention over configuration wirklich funktioniert oder ob das Problem in der Maven-Interpretation dieser Idee liegt.