Différences entre la gestion de la dépendance et les dépendances dans Maven

je suis à la mode en retard à cette question, mais je pense qu'il vaut la peine d'une réponse plus claire que celle acceptée (ce qui est correct, mais ne met pas l'accent sur la partie importante réelle, que vous devez déduire vous-même).

dans le POM parent, la principale différence entre le <dependencies> et <dependencyManagement> est la suivante:

artéfacts spécifiés dans la section <dependencies> sera TOUJOURS inclus en tant que dépendance de l'enfant module(s).

spécifiés dans la section <dependencyManagement> ne seront inclus dans le module enfant que s'ils sont également spécifiés dans la section <dependencies> du module enfant lui-même. Pourquoi est-ce bien que tu demandes? parce que vous spécifiez la version et/ou la portée dans le parent, et vous pouvez les laisser en dehors lorsque vous spécifiez les dépendances dans le POM enfant. Cela peut aider vous utilisez des versions unifiées pour les dépendances pour les modules enfants, sans spécifier la version dans chaque module enfant.

c'est comme vous l'avez dit; dependencyManagement est utilisé pour extraire toutes les informations de dépendances dans un fichier commun POM, simplifiant les références dans le fichier child POM.

il devient utile lorsque vous avez plusieurs attributs que vous ne voulez pas retaper sous plusieurs projets enfants.

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

la documentation sur le site de Maven est horrible. Ce que dependencyManagement fait est simplement de déplacer vos définitions de dépendances (version, exclusions, etc) vers le pom parent, puis dans le poms enfant vous avez juste à mettre le groupide et artifactId. C'est tout (sauf pour parent pom chaining et autres, mais ce n'est pas vraiment compliqué non plus - dependencyManagement gagne sur les dépendances au niveau parent - mais si vous avez une question à ce sujet ou des importations, la documentation Maven est un peu meilleure).

après avoir lu tous les déchets 'a', 'b', 'c' sur le site de Maven et avoir été confus, j'ai réécrit leur exemple. Donc si vous aviez 2 projets (proj1 et proj2) qui partagent une dépendance commune (betaShared), vous pourriez déplacer cette dépendance jusqu'à la pom du parent. Pendant que vous y êtes, vous pouvez également passer toutes les autres dépendances (alpha et charlie), mais seulement si elle fait sens pour votre projet. Ainsi, pour la situation décrite dans 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>

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 progressif:

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 mes modules Child A , Child B et Child C :

• Implicilty héritée par l'enfant poms
• un seul endroit pour gérer
• Pas besoin de redeclare rien de l'enfant poms
• je peux encore changer de nom et remplacer version 18.0 dans un Child B si je le veux.

mais que se passe-t-il si je n'ai pas besoin de goyave dans Child C , ni dans le futur Child D et Child E modules?

ils en hériteront encore et cela n'est pas désiré! C'est tout comme Java God Object code smell, où vous héritez de quelques bits utiles d'une classe, et une tonne de choses indésirables ainsi.

c'est ici que <dependencyManagement> entre en jeu. Lorsque vous ajoutez cela à votre pom parent, tous les modules de votre enfant STOP seeing it . Et donc vous êtes forcé d'aller dans chaque module individuel qui en a besoin et le déclarer à nouveau ( Child A et Child B , sans la version bien.)

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

Si la dépendance est définie dans le pom du dependencyManagement élément, le projet enfant n'a pas à mentionner la version de la dépendance. si le projet enfant définissait une version, il supplanterait la version listée au niveau supérieur La section Gestion de la dépendance de POM. C'est-à-dire que la version dependencyManagement utilisé lorsque l'enfant ne déclare pas une version directement.

il y a quelques réponses soulignant les différences entre <depedencies> et <dependencyManagement> tags avec maven.

cependant, peu de points développés ci-dessous d'une manière concise:

1. <dependencyManagement> permet de consolider toutes les dépendances (utilisées au niveau de la pom enfant) utilisées à travers différents modules -- clarté , gestion de la version de la dépendance centrale
2. <dependencyManagement> permet de facilement mettre à niveau/déclasser les dépendances en fonction des besoins, dans d'autres scénarios cela doit être exercé au niveau de chaque pom enfant -- consistency 1519170920"
3. dépendances <dependencies> tag est toujours importés, tandis que les dépendances fourni à <dependencyManagement> dans le pom parent sera importé uniquement si l'enfant pom est entrée dans sa <dependencies> tag.

dans le POM parent, la principale différence entre le <dependencies> et <dependencyManagement> est la suivante:

spécifiés dans la section <dependencies> seront toujours inclus comme une dépendance du(DES) module (s) enfant (s).

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 bien que tu demandes? parce que vous spécifiez la version et / ou la portée dans le parent, et vous pouvez les laisser en dehors lorsque vous spécifiez les dépendances dans la POM enfant. Cela peut vous aider à utiliser les versions unifiées pour les dépendances pour les modules enfants, sans spécifier la version dans chaque module enfant.

dans Eclipse, il y a une caractéristique supplémentaire dans le dependencyManagement . Quand dependencies est utilisé sans lui, les dépendances non-trouvées sont noté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 ces...)