Quelle est la différence dans maven entre les balises dependency et plugin dans le pom xml ?

Question

Je suis nouveau dans l'outil maven, j'ai fait un projet avec Spring et Hibernate et ils sont configurés dans pom.xml comme plugins, mais JUnit est marqué comme dépendance. Ma question est la suivante : quelle est la logique derrière l'un en tant que plugin et l'autre en tant que dépendance ?

Answer 1

Les plugins et les dépendances sont tous deux des fichiers Jar.

Mais la différence entre les deux est que la plupart du travail dans maven est effectué en utilisant des plugins, alors que la dépendance est juste un fichier Jar qui sera ajouté au classpath lors de l'exécution des tâches.

Par exemple, vous utilisez un plugin de compilation pour compiler les fichiers java. Vous ne pouvez pas utiliser compiler-plugin comme dépendance, car cela ne fera qu'ajouter le plugin au classpath, et ne déclenchera aucune compilation. Les fichiers Jar à ajouter au classpath lors de la compilation du fichier seront spécifiés en tant que dépendance.

Il en va de même pour votre scénario. Vous devez utiliser spring-plugin pour exécuter certains exécutables de spring [ Je ne suis pas sûr de savoir à quoi servent les spring-plugins. Je fais juste une supposition ici ]. Mais vous avez besoin de dépendances pour exécuter ces exécutables. Et Junit est étiqueté sous dépendance puisqu'il est utilisé par surefire-plugin pour exécuter les tests unitaires.

Ainsi, nous pouvons dire que le plugin est un fichier Jar qui exécute la tâche, et que la dépendance est un Jar qui fournit les fichiers de classe pour exécuter la tâche.

J'espère que cela répond à votre question !

Answer 2

Maven lui-même peut être décrit comme un robot ménager qui possède de nombreuses unités différentes pouvant être utilisées pour accomplir différentes tâches. Ces unités sont appelées plugins. Par exemple, pour compiler votre projet, Maven utilise maven-compiler-plugin pour exécuter des tests - maven-surefire-plugin et ainsi de suite.

Une dépendance, en termes de maven, est un paquet de classes dont dépend votre projet. Il peut s'agir de jar, war, etc. Par exemple, si vous voulez être en mesure d'écrire des tests JUnit, vous devrez utiliser les annotations et les classes JUnit et donc déclarer que votre projet dépend de JUnit.

Answer 3

Les plugins et les dépendances sont des choses très différentes et complémentaires.

Quels sont les plugins ?

Les plugins exécutent des tâches pour une construction Maven. Ils ne sont pas intégrés à l'application.

C'est le cœur de Maven.
Toute tâche exécutée par Maven est réalisée par des plugins .
Il existe deux catégories de plugins : le site build y el reporting plugins :

• Les plugins de construction seront exécutés pendant la construction et ils doivent être configurés dans le champ <build/> de l'élément POM.
• Les plugins de reporting seront exécutés lors de la génération du site et ils doivent être configurés dans l'onglet <reporting/ > élément du POM.

Selon l'objectif maven spécifié dans la ligne de commande (par exemple mvn clean , mvn clean package o mvn site ) , un cycle de vie spécifique sera utilisé et un ensemble spécifique d'objectifs de plugins sera exécuté.
Il existe trois cycles de vie de construction intégrés : default , clean y site . Le site default cycle de vie gère le déploiement de votre projet, le clean cycle de vie s'occupe du nettoyage du projet, tandis que le site gère la création de la documentation du site de votre projet.

Un objectif de plugin peut être lié à une phase spécifique d'un cycle de vie spécifique.
Par exemple, le maven-compiler-plugin lie par défaut le compile à la phase du cycle de vie : compile .
La plupart des plugins maven (aussi bien les plugins de base que les plugins tiers) privilégient la convention à la configuration. Ainsi, ils lient généralement un objectif de plugin à une phase spécifique pour rendre leur utilisation plus simple.

C'est plus propre et moins sujet aux erreurs :

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
</plugin>

que :

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
  <executions>
    <execution>
        <phase>compile</phase>
        <goals>
            <goal>compile</goal>
        </goals>
    </execution>
  </executions>
</plugin>

Quelles sont les dépendances ?

Les dépendances sont des artefacts/composants Maven nécessaires au projet.

Concrètement la plupart des dépendances sont des jar (c'est-à-dire des bibliothèques) mais il peut aussi s'agir d'autres types d'archives : war, ear, test-jar, ejb-client ... ou encore POM ou BOM.

Dans un pom.xml, les dépendances peuvent être spécifiées à plusieurs endroits : le <build><dependencies> partie , le dependencies management en partie ou toujours en a plugin déclaration ! En effet, certains plugins peuvent avoir besoin d'avoir des dépendances dans le classpath lors de leur exécution. Ce n'est pas courant mais cela peut arriver.
Voici un exemple tiré du documentation qui montre que plugin y dependency peuvent travailler ensemble :

Par exemple, le plugin Maven Antrun version 1.2 utilise la version Ant 1.6.5, si vous souhaitez utiliser la dernière version de Ant lors de l'exécution de ce plugin, il faut ajouter <dependencies> élément comme le suivant :

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.2</version>
        ...
        <dependencies>
          <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant</artifactId>
            <version>1.7.1</version>
          </dependency>
          <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant-launcher</artifactId>
            <version>1.7.1</version>
          </dependency>
         </dependencies>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Dans Maven, les dépendances sont référencées dans un format spécifique :
groupId:artifactId:packaging:classifier:version .
Le classificateur (qui est facultatif) et le conditionnement ( JAR par défaut) ne sont pas couramment spécifiés. Ainsi, le format commun dans le dependency La déclaration est plutôt : groupId:artifactId:version .
Voici un exemple de dépendance déclarée dans le fichier <build><dependencies> partie :

<build>
   <dependencies>
      <dependency>
         <groupId>org.hibernate</groupId>
         <artifactId>hibernate-core</artifactId>
         <version>5.2.14.Final</version>
      </dependency>
   <dependencies>
</build>

La dépendance n'a pas de liaison de phase comme les plugins pour répondre à la question "quand".
Mais elle a une contrepartie : la portée .
En effet, les dépendances déclarées sont utilisables par l'application à un moment précis selon la portée que nous avons définie pour celles-ci.
En scope est un concept central sur la façon dont une dépendance sera visible pour le projet.

La portée par défaut est compile . C'est le champ d'application le plus souvent nécessaire (convention sur configuration encore).
Le site compile scope signifie que la dépendance est disponible dans tous les classpaths d'un projet.

La portée définit dans quels classpaths la dépendance doit être ajoutée. Par exemple, en avons-nous besoin à la compilation et à l'exécution, ou seulement pour la compilation et l'exécution des tests ?

Par exemple, nous avons précédemment défini Hibernate en tant que compile car nous en avons besoin partout : compilation des sources, compilation des tests, exécution, etc. ....
Mais nous ne voulons pas que les bibliothèques de test soient intégrées dans l'application ou référencées dans le code source. Nous spécifions donc l'option test pour eux :

<build>
   <dependencies>
     <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.1.0</version>
        <scope>test</scope>
     </dependency>
   <dependencies>
</build>

Answer 4

Si, comme moi, vous venez d'une formation de front-end et que vous êtes familier avec Grunt et npm, pensez-y de la manière suivante :

D'abord vous courriez, disons, npm install grunt-contrib-copy --save-dev . C'est comme la méthode de maven <dependency></dependency> . Il télécharge les fichiers nécessaires à l'exécution d'une tâche de construction.

Ensuite, vous devez configurer la tâche dans Gruntfile.js

copy: {
  main: {
    src: 'src/*',
    dest: 'dest/',
  },
}

C'est comme la méthode maven <plugin>/<plugin> . Vous dites à l'outil de construction ce qu'il doit faire avec le code téléchargé par npm/ <dependency></dependency> .

Bien sûr, il ne s'agit pas d'une analogie exacte, mais elle est suffisamment proche pour vous aider à vous faire une idée.

Answer 5

Réponse en une ligne - compréhension de base

Plugin est un outil que vous utilisez à l'exécution de votre construction maven

Dépendance désigne le type de bibliothèque que vous utiliserez dans votre code