214 votes

Exclure toutes les dépendances transitives d'une seule dépendance

Dans Maven2, pour exclure une seule dépendance transitive, je dois faire quelque chose comme ceci:

 <dependency>
  <groupId>sample.group</groupId>
  <artifactId>sample-artifactB</artifactId>
  <version>1</version>
   <exclusions>
     <exclusion>
       <groupId>sample.group</groupId>
       <artifactId>sample-artifactAB</artifactId>
     </exclusion>
   </exclusions>
</dependency>
 

Le problème avec cette approche est que je dois le faire pour chaque dépendance transitive apportée par sample-artifactB .

Existe-t-il un moyen d'utiliser une sorte de caractère générique pour exclure toutes les dépendances transitives au lieu d'une par une?

295voto

enricopulatzo Points 1123

Ce qui a fonctionné pour moi (peut-être une nouvelle fonctionnalité de Maven) est simplement faire les caractères génériques, à l'exclusion de l'élément.

J'ai un multi-projet de module qui contient une "app" module qui est référencé dans deux GUERRE-emballés modules. L'un de ceux de la GUERRE-emballés modules vraiment seulement besoin de classes du domaine (et je n'ai pas séparés de l'application module encore). J'ai trouvé que cela fonctionne:

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>app</artifactId>
    <version>${project.version}</version>
    <exclusions>
        <exclusion>
            <groupId>*</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Le générique sur les deux groupId et artifactId exclure toutes les dépendances qui normalement se propager à travers le module à l'aide de cette dépendance.

52voto

whaley Points 8789

À ma connaissance il n'y en a pas. Alors qu'il semble pratique, je pense que ce genre de défaites le principe de base de la gestion de la dépendance.

Bien que pas aussi concis (et hackish) Esko solution, je vous recommande la création de vos propres pom pour la dépendance qui en a votre <exclusions>. Pour les projets qui ont besoin d'utiliser cette dépendance, définir la dépendance à votre personnalisé pom au lieu de la typique artefact. Tout en qui ne permet pas nécessairement de vous exclure toutes les dépendances transitives avec un seul <exclusion>, il ne permet pas, vous n'avez qu'à écrire votre dépendance à la fois et l'ensemble de vos projets n'avez pas besoin de maintenir inutiles et longues listes d'exclusion.

C'est le mieux que je peux suggérer, au moins.

30voto

Joshua Davis Points 1616

Une chose que j'ai trouvé utile:

Si vous mettez de la dépendance avec les exclusions dans le dependencyManagement section d'un parent, d'un POM de votre projet, ou dans un importables de gestion de la dépendance POM, alors vous n'avez pas besoin de répéter l'exclusion (ou de la version).

Par exemple, si votre parent a POM a:

<dependencyManagement>
    <dependencies>
    ...         
        <dependency>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
            <version>1.2.1</version>
            <exclusions>
                <exclusion>
                    <groupId>junit</groupId>
                    <artifactId>junit</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
     ....
  </dependencies>
</dependencyManagement>

Ensuite les modules dans votre projet peut simplement déclarer la dépendance:

        <dependency>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
        </dependency>

Dans le POM parent permettra de spécifier à la fois la version et les exclusions. J'utilise cette technique pour la presque totalité de nos projets et elle élimine beaucoup de répétition.

22voto

Esko Luontola Points 53877

Il y a trois ans , j'ai recommandé à l'aide de la Version 99 N'Existe Pas, mais maintenant, j'ai trouvé un meilleur moyen, surtout depuis la Version 99 est en mode hors connexion:

Dans votre projet parent POM, utilisez maven-enforcer-plugin à l'échec de la construire si les indésirables de la dépendance se glisse dans la construction. Cela peut être fait en utilisant le plugin est interdit dépendances de la règle:

<plugin>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>1.0.1</version>
    <executions>
        <execution>
            <id>only-junit-dep-is-used</id>
            <goals>
                <goal>enforce</goal>
            </goals>
            <configuration>
                <rules>
                    <bannedDependencies>
                        <excludes>
                            <exclude>junit:junit</exclude>
                        </excludes>
                    </bannedDependencies>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

Puis lorsque que vous alerte à propos d'un indésirable à la dépendance, de l'exclure dans le POM parent de l' <dependencyManagement> section:

<dependency>
    <groupId>org.springframework.batch</groupId>
    <artifactId>spring-batch-test</artifactId>
    <version>2.1.8.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </exclusion>
    </exclusions>
</dependency>

De cette façon, les indésirables de la dépendance ne s'affichent pas accidentellement (contrairement à la juste un <exclusion> qui est facile à oublier), il ne sera pas disponible, même au cours de la compilation (contrairement à provided de la portée), il n'y a pas de fausses dépendances (contrairement à la Version 99) et ça marchera sans dépôt personnalisée (à la différence de la Version 99). Cette approche sera même travail basé sur l'artefact version, les classificateurs, la portée ou l'intégralité d'un groupId - voir la documentation pour plus de détails.

9voto

Peter Points 4694

Actuellement, il n'y a aucun moyen d'exclure plus d'une dépendance transitive à la fois, mais il existe une demande de fonctionnalité pour cela sur le site JAVA de Maven:

http://jira.codehaus.org/browse/MNG-2315

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X