2011-01-17 15 views
62

Ich versuche eine "generische" Möglichkeit zu finden, eine transitive Abhängigkeit auszuschließen, ohne sie von allen Abhängigkeiten, die davon abhängen, auszuschließen. Zum Beispiel, wenn ich slf4j ausschließen will, muss ich Sie wie folgt vor:Gibt es eine Möglichkeit, eine Maven-Abhängigkeit global auszuschließen?

<dependency> 
    <groupId>org.hibernate</groupId> 
    <artifactId>hibernate-jmx</artifactId> 
    <version>3.3.2.GA</version> 
    <exclusions> 
     <exclusion> 
     <groupId>org.slf4j</groupId> 
     <artifactId>slf4j-api</artifactId> 
     </exclusion> 
    </exclusions> 
    </dependency> 
    <dependency> 
    <groupId>org.hibernate</groupId> 
    <artifactId>hibernate-entitymanager</artifactId> 
    <version>3.4.0.GA</version> 
    <type>jar</type> 
    <exclusions> 
     <exclusion> 
     <groupId>org.slf4j</groupId> 
     <artifactId>slf4j-api</artifactId> 
     </exclusion> 
    </exclusions> 
    </dependency> 

Dies ist zum Teil die pom-Datei zu bereinigen, teilweise zu vermeiden, Probleme in der Zukunft mit Menschen Abhängigkeiten hinzufügen, die auf dieser ausgeschlossen Abhängigkeit abhängen - und vergessen, es auszuschließen.

Gibt es einen Weg?

+2

tritt das Problem nicht lösen, aber Maven-Enforcer-Plugin hat eine [banned Abhängigkeiten verfügen] (https://maven.apache.org/ enforcer/enforcer-rules/bannedDependencies.html), die den Build scheitern lassen, wenn sich unerwünschte Abhängigkeiten einschleichen. Sie müssen sie dennoch manuell ausschließen: -/ – dnault

+0

Eine alternative Antwort finden Sie hier: http://stackoverflow.com/a/39979760/363573 – Stephan

Antwort

49

Hilft das? http://jlorenzen.blogspot.com/2009/06/maven-global-excludes.html

„Angenommen, ich möchte avalon-Rahmen aus meiner WAR auszuschließen, möchte ich hinzufügen, die meine Projekte nach POM mit einem Umfang von zur Verfügung gestellt. Dies funktioniert in allen transitiven Abhängigkeiten und ermöglicht es Ihnen, es einmal zu spezifizieren.

<dependencies> 
    <dependency> 
     <artifactId>avalon-framework</artifactId> 
     <groupId>avalon-framework</groupId> 
     <version>4.1.3</version> 
     <scope>provided</scope> 
    </dependency> 
</dependencies> 

Dies funktioniert sogar, wenn Sie es im übergeordneten POM angeben, was verhindern würde, dass Projekte dies in allen untergeordneten POMs deklarieren müssen. "

+1

Es hat den Trick gemacht, perfekt! –

+36

Es ist immernoch nur ein partieller Hack - die Abhängigkeit wird nicht innerhalb des Build-Artefakts enden, aber es ist immer noch während der Tests verfügbar. –

+0

@TuukkaMustonen Was ist mit dem 'Laufzeit'-Bereich anstelle von' bereitgestellten' Bereich? – Stephan

14

Ich habe ein leeres Glas und erstellt diese Abhängigkeit:

<dependency> 
    <groupId>commons-logging</groupId> 
    <artifactId>commons-logging</artifactId> 
    <scope>system</scope> 
    <systemPath>${basedir}/src/lib/empty.jar</systemPath> 
    <version>0</version> 
</dependency> 

Es weil ab jetzt nicht perfekt ist auf ein leeres Glas in Ihrem Kompilierung/Testpfad haben. Aber das ist nur kosmetisch.

3

Zur Erinnerung, hier ist die Antwort von Maven offizieller Dokumentation:

Warum Ausschlüsse auf einer Pro-Abhängigkeit Basis erfolgen, und nicht auf der POM Ebene

Dies ist vor allem Damit wird sichergestellt, dass das Abhängigkeitsdiagramm vorhersagbar ist und Vererbungseffekte den Ausschluss einer Abhängigkeit verhindern, die nicht ausgeschlossen werden sollte. Wenn Sie zu der Methode des letzten Ausweges kommen und einen Ausschluss machen müssen, sollten Sie absolut sicher sein, welche Ihrer Abhängigkeiten diese unerwünschte transitive Abhängigkeit mit sich bringt.

Will man ein Build robuster machen, ein Versionsbereich verwendet werden kann. Dies würde sicherstellen, dass keine neuere Version der Abhängigkeit das Projekt beeinträchtigen kann.

<dependency> 
    <groupId>org.slf4j</groupId> 
    <artifactId>slf4j-api</artifactId> 
    <version>[1.4.2,)</version> 
    <scope>provided</scope> 
</dependency> 

Alle slf4j-api Version> = 1.4.2 wird als angeboten betrachtet werden (im Lieferumfang enthalten) zur Laufzeit, entweder durch das JDK selbst oder ein Behälter.

Referenzen

2

auf dnault's comment erweitern:

One die Maven Enforcer plugin's Banned Dependencies rule Abhängigkeiten verwenden können, um sicherzustellen, sind ausgeschlossen. Man muss sie immer noch manuell ausschließen, aber der Build wird fehlschlagen, wenn jemand versehentlich die Abhängigkeit an anderer Stelle hinzufügt.

<dependencies> 
    <dependency> 
    <groupId>org.hibernate</groupId> 
    <artifactId>hibernate-jmx</artifactId> 
    <version>3.3.2.GA</version> 
    <exclusions> 
     <exclusion> 
     <groupId>org.slf4j</groupId> 
     <artifactId>slf4j-api</artifactId> 
     </exclusion> 
    </exclusions> 
    </dependency> 
</dependencies> 

<plugins> 
    <plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-enforcer-plugin</artifactId> 
    <version>1.4.1</version> 
    <executions> 
     <execution> 
     <goals> 
      <goal>enforce</goal> 
     </goals> 
     <configuration> 
      <rules> 
      <bannedDependencies> 
       <excludes> 
       <exclude>org.slf4j:slf4j-api</exclude> 
       </excludes> 
      </bannedDependencies> 
      </rules> 
     </configuration> 
     </execution> 
    </executions> 
    </plugin> 
</plugins> 

Auch gibt es eine offene Feature Anfrage: MNG-1977 Global dependency exclusions

Verwandte Themen