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

Quelle est la difference entre dependencyManagementet dependencies? J'ai vu les documents sur le site Web d'Apache Maven. Il semble qu'une dépendance définie sous le dependencyManagementpuisse être utilisée dans ses modules enfants sans spécifier la version.

Par exemple:

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

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

Puis chez l'enfant de Pro-par, je peux utiliser la 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 pom parent? Pourquoi ne pas le définir directement dans le module nécessaire?

La 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 plusieurs) qui hérite d'un parent commun.

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

Je suis à la mode en retard à cette question, mais je pense que cela vaut 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 vous déduire).

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

Les artefacts spécifiés dans la <dependencies>section seront TOUJOURS inclus en tant que dépendance du ou des modules enfants.

Les artefacts spécifiés dans la <dependencyManagement>section ne seront inclus dans le module enfant que s'ils ont également été spécifiés dans la <dependencies>section du module enfant lui-même. Pourquoi est-il bon de demander car vous spécifiez la version et / ou la portée dans le parent et vous pouvez les laisser de côté lorsque vous spécifiez les 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.

La documentation sur le site Maven est horrible. Ce que dependencyManagement fait, c'est simplement déplacer vos définitions de dépendances (version, exclusions, etc.) vers le pom parent, puis dans les poms enfants, il vous suffit de mettre groupId et artifactId. C'est tout (sauf pour le chaînage de pom parent et autres, 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 importe, la documentation Maven est un peu meilleure).

Après avoir lu toutes les ordures «a», «b», «c» sur le site de Maven et être confus, j'ai réécrit leur exemple. Donc, si vous aviez 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 vers le haut toutes les autres dépendances (alpha et charlie) mais uniquement 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>

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

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

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

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

Voici un exemple incrémentiel:

Je déclare dans mon parentpom:

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

boom! Je l' ai dans mes Child A, Child Bet Child Cmodules:

• Implicité héritée des enfants pompons
• Un seul endroit pour gérer
• Pas besoin de redéclarer quoi que ce soit dans les pompons pour enfants
• Je peux encore redelcare et override à version 18.0un Child Bsi je veux.

Mais que se passe-t-il si je finis par ne pas avoir besoin de goyave Child C, ni à l'avenir Child Dni de Child Emodules?

Ils en hériteront toujours et ce n'est pas souhaité! C'est exactement comme l'odeur du code Java God Object, où vous héritez de quelques bits utiles d'une classe, ainsi que d'une tonne de choses indésirables.

C'est là <dependencyManagement>qu'entre en jeu. Lorsque vous ajoutez cela à votre pom parent, tous vos modules enfants ARRÊTENT de le voir . Et donc vous êtes obligé d'aller dans chaque module individuel qui en a besoin et de le déclarer à nouveau ( Child Aet Child B, sans la version cependant).

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

Il y a quelques réponses décrivant les différences entre <depedencies>et les <dependencyManagement>balises avec maven.

Cependant, quelques points développés ci-dessous de manière concise:

1. <dependencyManagement>permet de consolider toutes les dépendances (utilisées au niveau du pom enfant) utilisées sur différents modules - clarté , gestion centralisée des versions des dépendances
2. <dependencyManagement>permet de mettre à niveau / rétrograder facilement les dépendances en fonction des besoins, dans un autre scénario, cela doit être exercé à chaque niveau de pom enfant - cohérence
3. les dépendances fournies dans la <dependencies>balise sont toujours importées, tandis que les dépendances fournies <dependencyManagement>dans le parent pom ne seront importées que si le pom enfant a une entrée respective dans sa <dependencies>balise.

Désolé, je suis très en retard à la fête.

Permettez-moi d'essayer d'expliquer la différence en utilisant la mvn dependency:treecommande

Considérez l'exemple ci-dessous

Parent POM - Mon projet

<modules>
    <module>app</module>
    <module>data</module>
</modules>

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

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.9</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Child POM - module de données

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
</dependencies>

Child POM - module d'application (n'a pas de dépendance supplémentaire, donc laisser les dépendances vides)

 <dependencies>
</dependencies>

Lors de l'exécution de la mvn dependency:treecommande, nous obtenons le résultat suivant

Scanning for projects...
------------------------------------------------------------------------
Reactor Build Order:

MyProject
app
data

------------------------------------------------------------------------
Building MyProject 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ MyProject ---
com.iamvickyav:MyProject:pom:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building app 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ app ---
com.iamvickyav:app:jar:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building data 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ data ---
com.iamvickyav:data:jar:1.0-SNAPSHOT
+- org.apache.commons:commons-lang3:jar:3.9:compile
\- com.google.guava:guava:jar:19.0:compile

Google goyave est répertorié comme dépendance dans chaque module (y compris le parent), tandis que l' apache commons est répertorié comme dépendance uniquement dans le module de données (pas même dans le module parent)

Si la dépendance a été définie dans l'élément dependencyManagement du pom de niveau supérieur, le projet enfant n'a pas dû répertorier explicitement la version de la dépendance. si le projet enfant définissait une version, il remplacerait la version répertoriée dans la section dependencyManagement du POM de niveau supérieur. Autrement dit, la version dependencyManagement n'est utilisée que lorsque l'enfant ne déclare pas directement une version.

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

Les artefacts spécifiés dans la <dependencies>section seront TOUJOURS inclus en tant que dépendance du ou des modules enfants.

Les artefacts spécifiés dans la section ne seront inclus dans le module enfant que s'ils ont également été spécifiés dans la section du module enfant lui-même. Pourquoi est-il bon de demander? car vous spécifiez la version et / ou la portée dans le parent et vous pouvez les laisser de côté lorsque vous spécifiez les 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.

Dans mes propres mots, votre parent-projectaide vous fournit 2 types de dépendances:

• dépendances implicites : toutes les dépendances définies dans la <dependencies>section de votre parent-projectsont héritées par tous leschild-projects
• dépendances explicites : permet de sélectionner, les dépendances à appliquer dans votre child-projects. Ainsi, vous utilisez la <dependencyManagement>section, pour déclarer toutes les dépendances que vous allez utiliser dans vos différents child-projects. La chose la plus importante est que, dans cette section, vous définissez un <version>afin que vous n'ayez pas à le déclarer à nouveau dans votre child-project.

Le <dependencyManagement>point de vue (corrigez-moi si je me trompe) est juste utile en vous aidant à centraliser la version de vos dépendances. C'est comme une sorte de fonction d'aide.

Dans Eclipse, il existe une autre fonctionnalité dans le dependencyManagement. Quand dependenciesest utilisé sans lui, les dépendances non trouvées sont notées dans le fichier pom. Si dependencyManagementest 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 ...)

La différence entre les deux est mieux apportée dans ce qui semble une définition nécessaire et suffisante de l'élément dependencyManagement disponible dans les documents du site Web Maven:

dependencyManagement

"Informations de dépendance par défaut pour les projets qui héritent de celui-ci. Les dépendances de cette section ne sont pas immédiatement résolues. Au lieu de cela, lorsqu'un POM dérivé de celui-ci déclare une dépendance décrite par un groupId et un artifactId correspondants, la version et d'autres valeurs de cette section sont utilisés pour cette dépendance s'ils ne sont pas déjà spécifiés. " [ https://maven.apache.org/ref/3.6.1/maven-model/maven.html ]

Il doit être lu avec plus d'informations disponibles sur une autre page:

«..L'ensemble minimal d'informations pour faire correspondre une référence de dépendance à une section dependencyManagement est en fait {groupId, artifactId, type, classifier}. Dans de nombreux cas, ces dépendances feront référence à des artefacts jar sans classificateur. Cela nous permet de raccourcir l'identité définie sur {groupId, artifactId}, car la valeur par défaut pour le champ type est jar et le classificateur par défaut est null. " [ https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html ]

Ainsi, tous les sous-éléments (portée, exclusions, etc.) d'un élément de dépendance - autres que groupId, artifactId, type, classifier, et pas seulement la version - sont disponibles pour le verrouillage / par défaut au point (et donc hérités de à partir de là) vous spécifiez la dépendance dans un élément dependencyElement. Si vous aviez spécifié une dépendance avec les sous-éléments type et classifier (voir la première page Web citée pour vérifier tous les sous-éléments) comme non jar et non null respectivement, vous auriez besoin de {groupId, artifactId, classifier, type} pour référencer (résoudre) cette dépendance à tout moment dans un héritage provenant de l'élément dependencyManagement. Sinon, {groupId, artifactId} suffirait si vous n'avez pas l'intention de remplacer les valeurs par défaut pour le classificateur et le type (jar et null respectivement). Par défaut, c'est un bon mot-clé dans cette définition; tout sous-élément (autre que groupId,

Ainsi, tout élément de dépendance en dehors de dependencyManagement, que ce soit en tant que référence à un élément de dependencyManagement ou en tant que autonome est immédiatement résolu (c'est-à-dire installé dans le référentiel local et disponible pour les chemins de classe).