Question Différences entre dépendancesManagement et dépendances dans Maven


Quelle est la différence entre dependencyManagement et dependencies? J'ai vu les docs sur le site web d'Apache Maven. Il semble qu'une dépendance définie sous la dependencyManagement peut être utilisé dans ses modules enfants sans spécifier la version.

Par exemple:

Un projet parent (Pro-par) définit une dépendance sous la dependencyManagement:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8</version>
    </dependency>
 </dependencies>
</dependencyManagement>

Alors chez l'enfant de Pro-par, je peux utiliser le junit:

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
 </dependencies>

Cependant, je me demande s'il est nécessaire de définir junit dans le parent pom? Pourquoi ne pas le définir directement dans le module nécessaire?


502
2018-04-12 02:43


origine


Réponses:


Gestion des dépendances permet de consolider et de centraliser la gestion des versions de dépendance sans ajouter de dépendances héritées par tous les enfants. Ceci est particulièrement utile lorsque vous avez un ensemble de projets (c'est-à-dire plus d'un) qui hérite d'un parent commun.

Un autre cas d'utilisation extrêmement important dependencyManagement est le contrôle des versions des artefacts utilisés dans les dépendances transitives. C'est difficile à expliquer sans exemple. Heureusement, ceci est illustré dans la documentation.


321
2018-04-12 03:31



Je suis très en retard sur cette question, mais je pense que cela vaut une réponse plus claire que celle acceptée (ce qui est correct, mais ne souligne pas la partie importante, que vous devez vous déduire).

Dans le POM parent, la principale différence entre <dependencies> et <dependencyManagement> est-ce:

Artefacts spécifiés dans le <dependencies> section sera TOUJOURS incluse en tant que dépendance du ou des module (s) enfant (s).

Artefacts spécifiés dans le <dependencyManagement> section, ne seront inclus dans le module enfant que s'ils sont également spécifiés dans le <dependencies> section du module enfant lui-même. Pourquoi est-ce que c'est bon? car vous spécifiez la version et / ou la portée dans le parent et vous pouvez les ignorer lors de la spécification des dépendances dans le POM enfant. Cela peut vous aider à utiliser des versions unifiées pour les dépendances des modules enfants, sans spécifier la version dans chaque module enfant.


386
2018-05-17 15:49



C'est comme tu l'as dit. dependencyManagementest utilisé pour extraire toutes les informations de dépendance dans un fichier POM commun, en simplifiant les références dans le fichier POM enfant.

Cela devient utile lorsque vous avez plusieurs attributs que vous ne voulez pas retaper dans plusieurs projets enfants.

Finalement, dependencyManagement peut être utilisé pour définir une version standard d'un artefact à utiliser sur plusieurs projets.


41
2018-04-12 03:08



le Documentation sur le site de Maven est horrible. Ce que dependencyManagement fait c'est simplement déplacer vos définitions de dépendances (version, exclusions, etc) jusqu'au parent pom, puis dans les poms enfants, il suffit de mettre le groupId et artefactId. C'est tout (sauf pour le chaînage parent et similaire, mais ce n'est pas vraiment compliqué non plus - dependencyManagement l'emporte sur les dépendances au niveau parent - mais si vous avez une question à ce sujet ou des imports, la documentation Maven est un peu mieux).

Après avoir lu toutes les ordures 'a', 'b', 'c' sur le site Maven et avoir été confus, j'ai réécrit leur exemple. Donc, si vous avez 2 projets (proj1 et proj2) qui partagent une dépendance commune (betaShared), vous pouvez déplacer cette dépendance vers le pom parent. Pendant que vous y êtes, vous pouvez également déplacer toutes les autres dépendances (alpha et charlie) mais seulement si cela a du sens pour votre projet. Donc, pour la situation décrite dans les phrases précédentes, voici la solution avec dependencyManagement dans le pom parent:

<!-- ParentProj pom -->
<project>
  <dependencyManagement>
    <dependencies>
      <dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
        <groupId>alpha</groupId>
        <artifactId>alpha</artifactId>
        <version>1.0</version>
        <exclusions>
          <exclusion>
            <groupId>zebra</groupId>
            <artifactId>zebra</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
      <dependency>
        <groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
        <artifactId>charlie</artifactId>
        <version>1.0</version>
        <type>war</type>
        <scope>runtime</scope>
      </dependency>
      <dependency> <!-- defining betaShared here makes a lot of sense -->
        <groupId>betaShared</groupId>
        <artifactId>betaShared</artifactId>
        <version>1.0</version>
        <type>bar</type>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

<!-- Child Proj1 pom -->
<project>
  <dependencies>
    <dependency>
      <groupId>alpha</groupId>
      <artifactId>alpha</artifactId>  <!-- jar type IS DEFAULT, so no need to specify in child projects -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId>
      <artifactId>betaShared</artifactId>
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

<!-- Child Proj2 -->
<project>
  <dependencies>
    <dependency>
      <groupId>charlie</groupId>
      <artifactId>charlie</artifactId>
      <type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId> 
      <artifactId>betaShared</artifactId> 
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

37
2018-03-25 21:55



Si la dépendance était définie dans l'élément dependencyManagement de pom de niveau supérieur, le projet enfant n'avait pas besoin de répertorier explicitement la version de la dépendance. Si le projet enfant a défini une version, il remplace la version répertoriée dans le niveau supérieur La section dependencyManagement de POM. Autrement dit, la version dependencyManagement est seulement utilisé lorsque l'enfant ne déclare pas directement une version.


8
2018-02-11 14:18



Il y a encore une chose qui n'est pas assez mise en évidence, à mon avis, et c'est héritage indésirable.

Voici un exemple incrémentiel:

Je déclare dans mon parent pom:

<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>19.0</version>
        </dependency>
</dependencies>

boom! Je l'ai dans mon Child A, Child B et Child C modules:

  • Implicilty hérité par les enfants poms
  • Un lieu unique à gérer
  • Pas besoin de redéclairer quoi que ce soit dans les poms enfants
  • Je peux encore redelcare et passer outre à version 18.0 dans un Child B si je veux.

Mais si je finis par ne pas avoir besoin de goyave dans Child C, et ni dans le futur Child D et Child E modules?

Ils vont toujours en hériter et c'est indésirable! C'est exactement comme l'odeur du code d'objet Java de Dieu, où vous héritez de quelques bits utiles d'une classe, et d'un tas de choses non désirées.

C'est ici que <dependencyManagement> entre en jeu. Lorsque vous ajoutez ceci à votre pom parent, tous vos modules enfants Arrêtez de le voir. Et ainsi vous êtes forcé pour entrer dans chaque module individuel qui en a besoin et le déclarer à nouveau (Child A et Child B, sans la version cependant).

Et, évidemment, vous ne le faites pas pour Child C, et donc votre module reste mince.


6
2017-12-17 11:27



Il y a quelques réponses soulignant les différences entre <depedencies> et <dependencyManagement> Mots-clefs avec maven.

Cependant, quelques points ont été développés de manière concise:

  1. <dependencyManagement> permet de consolider toutes les dépendances (utilisées au niveau pom enfant) utilisées dans différents modules - clarté, gestion de version de dépendance centrale
  2. <dependencyManagement> permet de mettre à niveau / dégrader facilement les dépendances en fonction des besoins, dans d'autres cas cela doit être exercé à chaque niveau d'enfant pom - cohérence
  3. dépendances fournies dans <dependencies> tag est toujours importé, alors que les dépendances fournies <dependencyManagement> dans le parent pom sera importé seulement si l'enfant pom a l'entrée respective dans son <dependencies> marque.

6
2018-04-18 14:38



Dans le POM parent, la principale différence entre <dependencies> et <dependencyManagement> est-ce:

Artefacts spécifiés dans le <dependencies> section sera TOUJOURS incluse en tant que dépendance du ou des module (s) enfant (s).

Les artefacts spécifiés dans la section ne seront inclus dans le module enfant que s'ils sont également spécifiés dans la section du module enfant lui-même. Pourquoi est-ce que c'est bon? car vous spécifiez la version et / ou la portée dans le parent et vous pouvez les ignorer lors de la spécification des dépendances dans le POM enfant. Cela peut vous aider à utiliser des versions unifiées pour les dépendances des modules enfants, sans spécifier la version dans chaque module enfant.


3
2018-01-10 02:34



Dans Eclipse, il y a une fonctionnalité supplémentaire dans dependencyManagement. Quand dependencies est utilisé sans elle, les dépendances infondées sont remarquées dans le fichier pom. Si dependencyManagement est utilisé, les dépendances non résolues restent inaperçues dans le fichier pom et les erreurs n'apparaissent que dans les fichiers java. (importations et autres ...)


2
2017-12-18 22:54