Les différences entre les dependencyManagement et dépendances Maven

https://stackoverflow.com/questions/2619598

26-09-2019
|

Question

Quelle est la différence entre dependencyManagement et dependencies? Je l'ai vu la documentation sur le site Web 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-pair) 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 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 la pom-mère? Pourquoi ne pas définir directement dans le module nécessaire?

La solution

La gestion des dépendances permet de consolider et 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 (à savoir plus d'un) qui hérite d'un parent commun.

Un autre cas d'utilisation extrêmement important de dependencyManagement est le contrôle des versions d'objets utilisés dans les dépendances transitif. Il est difficile d'expliquer sans exemple. Heureusement, cela est illustré dans la documentation.

Autres conseils

Je suis peu en retard à cette question, mais je pense que ça vaut une réponse plus claire que celle acceptée (ce qui est correct, mais ne met pas la partie importante réelle, que vous devez vous en déduire).

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

Artifacts spécifiés dans le <dependencies> sera toujours inclus en tant que dépendance du module d'enfant (s).

Les artefacts spécifiés dans la section <dependencyManagement> , ne sera inclus dans le module enfant si elles ont été spécifiées dans le <dependencies> du module enfant lui-même. Pourquoi est-ce bien vous demandez? parce que vous spécifiez la version et / ou la portée du parent, et vous pouvez les laisser en spécifiant les dépendances chez l'enfant POM. Cela peut vous aider à utiliser les versions unifiées pour les dépendances pour modules enfants, sans spécifier la version dans chaque module enfant.

La documentation sur le site Maven est horrible. Qu'est-ce que dependencyManagement fait est simplement déplacer vos définitions de dépendance (version, exclusions, etc.) jusqu'à la pom-mère, puis dans les poms de l'enfant il vous suffit de mettre le groupId et artifactId. C'est (sauf pour Enchaînement des pom-mère, etc., mais ce n'est pas vraiment compliqué soit - dependencyManagement l'emporte sur les dépendances au niveau des parents - mais si vous avez une question à ce sujet ou les importations, la documentation Maven est un peu mieux).

Après avoir lu tous les « a », « b », « c » ordures sur le site Maven et se confondre, je 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 à la pom-mère. Pendant que vous y êtes, vous pouvez également déplacer vers le haut toutes les autres dépendances (alpha et charlie), mais seulement si elle est logique pour votre projet. Donc, pour la situation décrite dans les phrases précédentes, voici la solution avec dependencyManagement dans la pom-mère:

<!-- 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 est comme vous l'avez dit; dependencyManagementis utilisé pour tirer toutes les informations de dépendance dans un fichier POM commun, ce qui simplifie les références dans le fichier enfant POM.

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

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

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

Voici un exemple supplémentaire:

Je déclare dans mon parent pom:

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

boum

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

Implicilty héritée par poms enfant
Un lieu unique pour gérer
Pas besoin de quoi que ce soit dans redéclarer poms enfant
je peux encore redelcare et override à version 18.0 dans un Child B si je veux.

Mais si je finis par ne pas avoir besoin de goyave dans Child C, ni à l'avenir Child D et des modules de Child E?

Ils seront encore Hériter et ce n'est pas souhaitable! Ceci est juste comme Java Dieu odeur de code objet, où vous héritez des bits utiles d'une classe, et un tonn de choses indésirables aussi bien.

C'est là <dependencyManagement> entre en jeu. Lorsque vous ajoutez ceci à votre pom-mère, tous vos modules enfants arrêt le voir . Et donc vous êtes forcé pour aller dans chaque module qui a besoin et déclarer à nouveau (Child A et Child B, sans la version cependant).

Et, de toute évidence, vous ne le faites pas pour Child C, et donc votre module reste maigre.

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

Cependant, quelques points ci-dessous élaboré d'une manière concise:

<dependencyManagement> permet de regrouper toutes les dépendances (utilisé au niveau de la pom enfant) utilisé dans différents modules - clarté , gestion des versions de dépendance centrale
<dependencyManagement> permet de facilement mettre à jour / dépendances de déclassement en fonction des besoins, dans un autre scénario ce doit être exercé à tous les niveaux de pom enfant - cohérence
dépendances fournies dans la balise <dependencies> est toujours importés, tandis que les dépendances fournies à <dependencyManagement> en pom-mère seront importés que si pom enfant a l'entrée respective dans sa balise de <dependencies>.

Si la dépendance a été définie dans l'élément dependencyManagement haut niveau pom, le projet enfant n'a pas à énumérer explicitement la version de la dépendance. si le projet enfant avait défini une version, il remplacer la version indiquée dans le haut niveau section dependencyManagement POM. Autrement dit, la version est seulement dependencyManagement utilisé lorsque l'enfant ne déclare pas une version directement.

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

Je vais essayer d'expliquer la différence en utilisant la commande mvn dependency:tree

Considérons le exemple ci-dessous

Parent POM - Projet Mon

<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 (a aucune dépendance supplémentaire, laissant ainsi les dépendances vide)

 <dependencies>
</dependencies>

En cours d'exécution commande mvn dependency:tree, nous obtenons 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 parent), alors que le apache communs est répertorié comme dépendance uniquement dans le module de données (même pas dans le module parent)

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

Artifacts spécifiés dans la section <dependencies> va toujours être inclus en tant que dépendance du module d'enfant (s).

Les artefacts spécifiés dans la section, ne sera inclus dans le module enfant si elles ont également été précisées dans la section du module enfant lui-même. Pourquoi est-ce bien vous demandez? parce que vous spécifiez la version et / ou la portée du parent, et vous pouvez les laisser en spécifiant les dépendances chez l'enfant POM. Cela peut vous aider à utiliser les versions unifiées pour les dépendances pour modules enfants, sans spécifier la version dans chaque module enfant.

Dans Eclipse, il y a une fonctionnalité de plus dans le dependencyManagement. Lorsque dependencies est utilisé sans elle, les dépendances sont remarqués dans non trouvés le fichier pom. Si dependencyManagement est utilisé, les dépendances non résolues restent inaperçues dans le fichier pom et les erreurs apparaissent uniquement dans les fichiers java. (importations et autres ...)

La différence entre les deux est mieux mis dans ce qui semble une définition nécessaire et suffisante de l'élément dependencyManagement disponible dans le site Maven docs:

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ésolu. Au lieu de cela, quand un POM dérivé de celui-ci déclare une dépendance décrite par un correspondant groupId et artifactId, la version et d'autres valeurs de cette section sont utilisés pour cette dépendance si elles ne sont pas déjà spécifiés « . [ https://maven.apache.org/ref/3.6 0,1 / maven-modèle / maven.html ]

Il doit être lu en même temps que quelques informations disponibles sur une autre page:

« .. l'ensemble minimal d'informations pour faire correspondre une référence de dépendance contre une section de dependencyManagement est en fait {groupId, artifactId, type, classificateur}. Dans de nombreux cas, ces dépendances se référeront aux artefacts jar sans classificateur. Cela nous permet de sténographie l'ensemble d'identité {groupId, artifactId}, étant donné que la valeur par défaut pour le champ de type est pot, et le classificateur par défaut est nul. »[ https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html ]

Ainsi, tous les sous-éléments (champ d'application, exclusions, etc.), d'un élément de dépendance - autres que groupId, artifactId, type, classificateur, et pas seulement la version - sont disponibles pour lockdown / défaut au point (et ainsi hérité à partir de là en avant) que vous spécifiez la dépendance dans un dependencyElement. Si vous spécifiez une dépendance du type et de sous-éléments classificateur (voir la page Web de première cité pour vérifier tous les sous-éléments) comme non jar et non nul respectivement, vous auriez besoin {groupId, artifactId, classificateur, type} de référence (résolution) que la dépendance à un point quelconque dans une source originale d'héritage de l'élément dependencyManagement. Sinon, {groupId, artifactId} suffirait si vous ne souhaitez pas remplacer les valeurs par défaut pour classificateur et le type (pot et nul respectivement). Donc, par défaut est un bon mot-clé dans cette définition; un sous-élément (s) (autres que groupId, artifactId, classificateur et le type, bien sûr) valeur explicitement affecté (s) à l'endroit où référencer une correction de la dépendance des valeurs par défaut de l'élément de dependencyManagement.

Ainsi, tout l'extérieur de l'élément de dépendance de dependencyManagement, que ce soit comme une référence à un élément ou en tant que dependencyManagement autonome est réglé immédiatement (par exemple installé dans le référentiel local et disponible pour classpaths).

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow