web-dev-qa-db-fra.com

Maven: Cycle de vie vs phase vs plugin vs objectif

Développeur relativement nouveau ici, même si je l'utilise depuis un moment, j'espère consolider mes fondamentaux Maven. Une partie de mon problème est que j'ai non une expérience de Ant, qui semble provenir de nombreuses explications. J'ai lu et regardé des tutoriels, et j'entends toujours les mêmes termes:

  • Cycle de la vie
  • Phase
  • Brancher
  • Objectif

D'après ce que j'ai appris, il semble que le cycle de vie soit le plus vaste du groupe et qu'il soit composé (ou complété par) de phases, de plugins et/ou d'objectifs.

Question: Pouvez-vous fournir des informations sur la relation entre ces termes et les exemples les plus courants?

Le plus explicite et basique, mieux c'est!

mavenmaven-3pom.xmlmaven-lifecycle
96
Jeff Levine

La réponse de @ Drejc n'est pas correct dans son intégralité.

En particulier:

Chacune de ces phases peut avoir un objectif à exécuter avant ou après une phase, par exemple:

• pré-installer - ...
• post-package - ...

Vous pouvez voir les objectifs sous forme de phases "insérées" supplémentaires si vous le souhaitez.

[Barré de déclarations incorrectes de ma part.]

Un cycle de vie Maven est un concept (abstrait) qui couvre toutes les étapes (ou mieux: toutes les étapes que les concepteurs Maven ont créées décidé de prendre en charge) pendant la durée de développement d'un projet. Ces étapes sont appelées phases dans la terminologie Maven.

Un plugin Maven est un conteneur pour/fournisseur de objectifs. Le code implémenté dans les objectifs est le véritable bourreau de travail. ( Maven, dans son cœur, ne fait que gérer des plugins et exécuter des objectifs ). Chacun des objectifs d'un plugin peut être assigné/lié à l'une des phases du cycle de vie.

Lors de l'appel de mvn <phase> _ Maven passe toutes les phases (à chaque fois) et exécute tous les objectifs (fourni par les plugins) qui ont été liés à l’une des phases avant et jusqu’à (et y compris) la phase donnée. S'il y a une phase sans but lié à celle-ci, rien n'est fait. Mais la phase est quand même passée.

C'est à dire. vous ne pouvez pas "'insérer' des 'phases supplémentaires" dans l'un des cycles de vie intégrés de Maven. Ils sont déjà là, toujours! Vous pouvez développer votre propre cycle de vie avec ses propres phases, mais cela va bien au-delà de la simple utilisation de Maven.

Les phases appelées "pré-installation" ou "post-package" n'existent pas.

Références:

63
Gerold Broser

Maven: Cycle de vie vs phase vs plugin vs objectif

Répondre tardivement pour clarifier encore un autre niveau de granularité manquant dans ce fil de discussion: exécutions (d'un objectif), qui sont les plus petites unités d'une construction Maven.

Par conséquent, nous avons des cycles de construction (essentiellement, un ensemble d’actions pour un objectif global spécifique), qui consiste en phases (granularité inférieure, une étape du cycle), qui peut appeler un ensemble d’objectifs configurés fournis par certains plugins . C'est-à-dire que Maven est (également) un exécuteur de plugins, chaque plugin peut offrir un ou plusieurs objectifs. Vous décidez ensuite (également) quel objectif est associé à quelle phase, la plupart du temps dans le cycle de vie par défaut (sans aucune, c'est-à-dire par défaut). Mais vous pouvez réellement avoir encore un autre niveau: les exécutions (du même objectif, du même plugin, ou des objectifs différents de différents plugins)

Une image que je me suis préparé à reprendre le tout enter image description here

Et en effet, voici comment Maven le montre (sa plus petite unité de travail) via la chaîne unique de son journal de construction:

plugin-artifactId:plugin-version:plugin-goal (goal-execution-id) @ project-name

Par exemple, nous aurions:

[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ sample-project ---

Ce qui signifie en effet (à travers différents niveaux de granularité):

  • pendant la phase compile (non mentionné, malheureusement)>
  • J'appelle le plugin Maven Compiler (artifactId et version)>
  • J'invoque son compile objectif>
  • tel que défini par le default-compile exécution

C'est unique parce qu'en effet vous pouvez avoir le même objectif (du même plugin) lié à différentes phases ou à la même phase mais à différentes exécutions (c'est-à-dire avec des configurations différentes). Le maven-compiler-plugin, par exemple, est également utilisé pendant le test-compile phase (une phase différente) pour compiler le code de test (via son testCompile objectif) dans une exécution différente (default-testCompile). Vous pouvez également compiler (à l'aide du même plugin et du même objectif) du code généré automatiquement au cours d'une phase différente, telle que définie par une exécution que vous avez spécifiée dans le POM (et éventuellement une configuration différente).

Les exécutions par défaut sont fournies directement via liaisons d'empaquetage Maven , c'est-à-dire par défaut (et en appliquant la convention de configuration) Maven appelle déjà certains objectifs (des plugins standard) au cours de certaines phases. Les identifiants d'exécution de ces invocations par défaut sont définis selon certaines conventions .

Cela explique également pourquoi si vous voulez vraiment remplacer un comportement par défaut (liaison) d'une construction Maven, vous devez spécifier (remplacer) exactement le même identifiant d'exécution dans votre POM pour le même plugin. Vous pouvez, par exemple, ignorer la compilation en définissant simplement une exécution du fichier maven-compiler-plugin avec le même default-compile id, mais lié à une phase non existante (ou vide).

Pour faire court : une exécution indique à Maven quel objectif exécuter avec quelle configuration dans quelle phase.

Certaines exécutions sont fournies par défaut (defaul bindings), ce qui explique pourquoi les lignes maven minimal pom de seulement 6 peuvent déjà le faire beaucoup (compiler, tester, empaqueter, etc.): exécuter les objectifs des plugins standards dans certaines phases: c'est la convention sur la configuration. Ensuite, via le pom.xml configuration vous pouvez ajouter des choses (exécutions) à la construction ou influencer le comportement de plugins déjà configurés (dans ce cas pas de executions section, mais seulement configuration suffirait).

Oui, vous pouvez ignorer les cycles de construction (et leurs phases) et invoquer directement les objectifs (des plugins). Imaginez ce qui suit:

mvn compiler:compile
mvn compiler:testCompile
mvn surefire:test
mvn jar:jar

(REMARQUE: vous pouvez également appeler en ligne dans un seul appel)

Nous compilons ici le code de l'application, le code de test, l'exécution des tests et le package: imaginez à quel point cela serait manuel, source d'erreurs, répétitif et fastidieux. La convention sur la configuration nous aide: Maven introduit les cycles de vie de la construction et les phases . Le cycle de vie par défaut (sans nom, c'est-à-dire celui par défaut) fournit une série de phases basées sur les meilleures pratiques et conventions (le mantra de Maven).
Si vous voulez obtenir le même résultat que précédemment, lancez simplement: mvn package et il compilera, testera et conditionnera automatiquement votre projet. Comment? invoquer des plugins. C'est-à-dire que les phases constituent un ensemble significatif et configurable d'exécutions de plugins (objectifs). Pour le rendre encore plus standard, Maven invoquera d’abord chaque phase précédente, de sorte que p. Ex. si vous voulez tester, vous serez sûr de compiler d’abord.

p.s. Notez que lorsque vous spécifiez plusieurs objectifs pour le même execution, vous verrez toujours clairement dans le journal de construction deux exécutions différentes (avec le même identifiant) pour les deux objectifs différents (par conséquent, Tuple toujours unique).

40
A_Di-Matteo

Nous remercions Sandeep Jindal et Premraj (à partir d’ici Quels sont les objectifs et les phases Maven et quelle est leur différence? ). Leur explication m'aide à comprendre.

J'ai créé quelques exemples de code complets et quelques explications simples ici https://www.surasint.com/maven-life-cycle-phase-and-goal-easy-explained/ . Je pense que cela peut aider les autres à comprendre et peut essayer quelque chose directement.

En bref, du lien, vous ne devriez pas essayer de comprendre les trois en même temps, vous devez d’abord comprendre la relation entre ces groupes:

  • Cycle de vie vs phase
  • Plugin vs objectif

1. Cycle de vie vs phase

Cycle de vie est un ensemble de phases , voir ici - Références de cycle de vie . Lorsque vous appelez une phase , toutes les phases sont également appelées avant celle-ci. .

Par exemple, le cycle de vie propre comporte 3 phases (: pré-nettoyage, nettoyage, post-nettoyage ).

mvn clean

Il appellera pré-nettoyer et propre .

2. Plugin vs objectif

L'objectif est comme une action dans le plugin . Donc, si le plugin est une classe, goal est une méthode.

vous pouvez appeler un objectif comme ceci:

mvn clean:clean

Cela signifie "appeler le but propre, dans le plugin clean" (Rien ne se rapporte ici à la phase de nettoyage. Ne laissez pas la Parole "nettoyer" qui vous dérange, ils ne sont pas les mêmes! Voir l'explication complète dans mon lien ci-dessus)

3. Maintenant, la relation entre phase et objectif:

La phase peut (avant) être liée à But (s) .Par exemple , normalement, la phase de nettoyage est liée à l’objectif de nettoyage. Alors, quand vous appelez cette commande:

mvn clean

Il appellera la phase de pré-nettoyage et la phase de nettoyage qui est liée à l'objectif Nettoyer: nettoyer.

C'est presque pareil que:

mvn pre-clean clean:clean
16
Surasin Tancharoen

Et tardivement un autre diagramme

  • Cycle de vie sous forme de rectangles jaunes
  • Phases des cycles de vie sous forme de rectangles bleus avec "appelable" phases en bleu plus foncé (c'est-à-dire que les phases avec hypénation ne sont généralement pas appelées à partir de la ligne de commande car ils peuvent ne pas être conçus pour laisser le projet dans un état bien défini).
  • Objectifs sous forme de losanges bleus. L'association/liaison "phase -> objectif" indiquée est celle du mode d'empaquetage "jar" . Chaque phase peut avoir des objectifs liés. Ceci est bien sûr valable pour chacun des cycles de vie, bien que les liaisons ne soient affichées que pour le cycle de vie "par défaut".
  • Plugins sous forme de rectangles gris coupés. Les plugins fournissent les objectifs pouvant être liés aux phases.

Maven Lifecycles, Phases, Goals, Plugins

14
David Tonhofer

Source: http://www.codetab.org/Apache-maven-tutorial/ , c'est vraiment un bon tutoriel

Les cycles de vie, les phases du cycle de vie, les plug-ins et les objectifs de plug-in sont au cœur de Maven.

  • La commande Maven mvn ne peut accepter que Lifecycle Phase ou Plugin Goal en tant qu'argument.
  • Maven est livré avec trois cycles de vie - défaut, propre et site.
  • Chaque cycle de vie est constitué de phases de cycle de vie et en tout, il y a 28 phases - défaut 21 ( valider, ..., compiler, ..., package, ..., installer, déployer), nettoyer 3 ( pré-nettoyage, nettoyage, post-nettoyage) et site 4 ( pré-site, site, post-site, site-deploy).
  • lorsqu'une phase du cycle de vie est appelée à l'aide de la commande mvn, toutes les phases précédentes sont exécutées les unes après les autres.
  • les phases du cycle de vie en elles-mêmes n’ont aucune possibilité d’accomplir une tâche et elles dépendent de plugins pour mener à bien cette tâche.
  • (== --- ==) Maven lie divers objectifs de plug-in aux phases de cycle de vie et aux objectifs de la tâche qui leur est confiée.

Lorsque nous exécutons " package mvn" dans un projet Java, Maven lie les objectifs du plug-in aux phases du cycle de vie, comme indiqué dans la figure suivante.

mvn-plugins-package-goal

10
Erlan

Donc, pour expliquer un peu plus loin comme indiqué ici

Les constructions Maven sont divisées en cycles de vie, à savoir:

  • nettoyer
  • build (par défaut)
  • site

Chacun de ces cycles est divisé en phases. Par exemple, la construction est divisée en phases telles que:

  • préparer des ressources
  • compiler
  • paquet
  • installer

Les phases ont des objectifs à exécuter avant avant - ou après après - une phase , par exemple:

  • pré-nettoyage - sera exécuté avant la phase de nettoyage
  • post-nettoyage - sera exécuté après la phase de nettoyage

Vous pouvez voir les objectifs sous forme de phases "insérées" supplémentaires si vous le souhaitez. Lisez ici ou jetez un oeil à @ réponse de Gerolds pour plus de détails.

7
Drejc

LifeCycle vs Phases: Life Cycle est une collection de phases. Lorsque vous appelez une phase, toutes les phases précédentes sont également appelées. Maven est livré avec 3 cycles de vie de construction intégrés comme:

  1. Cycle de vie propre - cela implique le nettoyage du projet (pour une nouvelle construction et un nouveau déploiement)
  2. Cycle de vie par défaut/génération: gère le déploiement complet du projet.
  3. Cycle de vie du site - cela gère la génération de la documentation du projet Java). enter image description here

Le cycle de vie d'un nettoyage comporte 3 phases: pré-nettoyage, nettoyage et post-nettoyage. Les phases de cycle de vie par défaut et de site sont identiques à celles illustrées.

3
Arun Raaj