Maven: Cycle de vie vs Phase vs Plugin vs Objectif [fermé]

Développeur relativement nouveau ici, même si je l'utilise depuis un petit moment, j'espère solidifier mes fondamentaux Maven. Une partie de mon problème est que je n'ai aucune expérience avec Ant, qui semble être à l'origine de nombreuses explications. J'ai lu et regardé des tutoriels, et j'entends 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 large du groupe et qu'il soit composé (ou complété par) de phases, de plugins et / ou d'objectifs.

Question : Pourriez-vous fournir des informations sur la manière dont ces termes sont liés et les exemples les plus courants?

Plus c'est explicite et basique, mieux c'est!

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

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

Lors de l'appel, mvn <phase> Maven passe toutes les phases (à chaque fois) et exécute tous les objectifs (fournis 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é, rien n'est fait. Mais la phase est quand même passée.

C'est-à-dire que vous ne pouvez pas "" insérer "de 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 tel quel.

Les objectifs peuvent également être exécutés directement, ce qui vous est dit lors de l'exécution mvnsans phase ni objectif [avec des sauts de ligne et raccourcis pour plus de lisibilité ici]:

You must specify a valid lifecycle phase or a goal in the format

<plugin-prefix>:<goal> or

<plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>.

Available lifecycle phases are:

... see actual output or 'Maven, Introduction to the Build Lifecycle' at 'References' below ...

Références:

• Maven, Introduction au cycle de vie de build
  

Si vous vous êtes déjà demandé comment Maven sait quoi faire sans aucune liaison d'objectif dans le POM, il y a un lien vers default-bindings.xmlà la fin qui se trouve dans <Your Maven installation>/lib/maven-core-x.y.z.jar/META-INF/plexus/default-bindings.xml.

Les phases des cycles de vie intégrés ( nettoyage , par défaut , site ) sont déclarées <Your Maven installation>/lib/maven-core-x.y.z.jar/META-INF/plexus/components.xmlsous .../<component>/<role>org.apache.maven.lifecycle.Lifecycle.

• Maven: The Complete Reference, Chapter 4. Le cycle de vie de build

• Maven par l'exemple, 3.5. Concepts de base

Maven: Cycle de vie vs Phase vs Plugin vs Objectif

Répondre tard pour clarifier encore un autre niveau de granularité manquant dans ce fil: les 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 (en gros, un ensemble d'actions pour un objectif global spécifique), qui se composent de phases (granularité inférieure, une étape de cycle), qui peuvent invoquer un ensemble d' objectifs configurés fournis par certains plugins . Autrement dit, Maven est (aussi) un exécuteur de plugin, chaque plugin peut offrir un ou plusieurs objectifs. Vous décidez alors (également) quel objectif est attaché à quelle phase, la plupart du temps dans le cycle de vie par défaut (sans aucun, c'est-à-dire la valeur par défaut). Mais vous pouvez en fait 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 photo que je préparais pour reprendre l'ensemble

Et en effet, c'est ainsi que Maven le montre (sa plus petite unité de travail) via la chaîne unique dans 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 compilephase (non mentionné, malheureusement)>
• J'invoque le plugin Maven Compiler ( artifactIdet version)>
• J'invoque son compileobjectif>
• tel que défini par l' default-compileexécution

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

Les exécutions par défaut sont fournies prêtes à l'emploi via les liaisons d'empaquetage Maven , c'est-à-dire que par défaut (et en appliquant la convention sur la configuration) Maven invoque déjà certains objectifs (des plugins standard) pendant certaines phases. Les identifiants d'exécution de ces appels 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, sauter la compilation en définissant simplement une exécution du maven-compiler-pluginavec le même default-compileidentifiant mais lié à une phase non existante (ou vide).

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

Certaines exécutions sont fournies par défaut (bindings par défaut), ce qui explique pourquoi le pom minimal maven de seulement 6 lignes peut déjà faire beaucoup (compiler, tester, package, etc.): exécuter les objectifs des plugins standard dans certaines phases: c'est la convention sur configuration. Ensuite, via la pom.xmlconfiguration, vous pouvez ajouter des éléments (exécutions) à la construction ou influencer le comportement des plugins déjà configurés (dans ce cas, aucune executionssection, mais configurationcela 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 en un seul appel)

Ici, nous compilons le code de l'application, le code de test, exécutons les tests et le package: imaginez à quel point cela serait manuel, sujet aux erreurs, répétitif et chronophage. La convention sur la configuration nous aide: Maven introduit des cycles et des phases de construction . Le cycle de vie par défaut (sans nom, c'est-à-dire la valeur par défaut), fournit une gamme de phases basées sur les meilleures pratiques et conventions (le mantra de Maven).
Si vous voulez obtenir la même chose que ci-dessus, exécutez simplement: mvn packageet il compilera, testera et conditionnera automatiquement votre projet. Comment? invoquer des plugins. Autrement dit, les phases sont un ensemble significatif et configurable d'exécutions de plugins (objectifs). Pour le rendre encore plus standard, pour chaque phase, Maven appellera d'abord n'importe quelle phase précédente, de sorte que, par exemple, si vous voulez tester, vous serez sûr que vous compilerez d'abord.

ps 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, un tuple toujours unique).

Crédit à Sandeep Jindal et Premraj (à partir d'ici Quels sont les objectifs et phases de 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 à essayer quelque chose directement.

En bref, à partir du lien, vous ne devez pas essayer de comprendre les trois à la fois, vous devez d'abord comprendre la relation dans ces groupes:

• Cycle de vie vs phase
• Plugin vs objectif

1. Cycle de vie vs phase

Cycle de vie est un ensemble de phases en séquence, voir ici Références du cycle de vie . Lorsque vous appelez une phase , il appellera également toutes les phases précédentes.

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

mvn clean

Il appellera pré-nettoyage et nettoyage .

2. Plugin vs Objectif

Le but est comme une action dans Plugin . Donc, si le plugin est une classe, le but est une méthode.

vous pouvez appeler un objectif comme celui-ci:

mvn clean:clean

Cela signifie "appeler l'objectif propre, dans le plugin propre" (Rien ne concerne la phase de nettoyage ici. Ne laissez pas le mot "nettoyer" vous dérouter, ce 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 (pré) établir un lien avec un ou plusieurs objectifs . Par exemple, normalement, la phase propre est liée à l'objectif propre. Ainsi, lorsque vous appelez cette commande:

mvn clean

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

C'est presque la même chose que:

mvn pre-clean clean:clean

Et tardivement un autre diagramme

• Cycles de vie sous forme de rectangles jaunes
• Les phases des cycles de vie sous forme de rectangles bleus avec des phases "appelables" 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 elles peuvent ne pas être conçues pour laisser le projet dans un état bien défini).
• Des buts comme des pastilles bleues. L'association / liaison "phase -> but" affichée est celle du mode de conditionnement "jar" . Chaque phase peut avoir des objectifs liés. Cela vaut bien sûr 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 écrêtés gris. Les plugins fournissent les objectifs qui peuvent être liés aux phases.

Source c'est vraiment un bon tutoriel

Les cycles de vie, les phases du cycle de vie, les plugins et les objectifs des plugins sont au cœur de Maven.

• La commande Maven mvn ne peut accepter que la phase de cycle de vie ou l'objectif du plug-in comme argument.
• Maven est livré avec trois cycles de vie: par défaut, propre et site.
• Chaque cycle de vie est composé de phases du cycle de vie et en tout, il y a 28 phases - par défaut 21 ( valider, ..., compiler, ..., empaqueter, ..., installer, déployer ), nettoyer 3 ( pré-nettoyer, clean, post-clean ) et site 4 ( pre-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 séquentiellement l'une après l'autre.
• Les phases du cycle de vie en elles-mêmes n'ont aucune capacité pour accomplir certaines tâches et elles s'appuient sur des plugins pour mener à bien la tâche.
• en fonction du projet et du type de packaging, Maven lie divers objectifs du plugin aux phases du cycle de vie et les objectifs exécutent la tâche qui leur est confiée.

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

Donc pour expliquer un peu plus comme indiqué ici

Les versions de Maven sont divisées en cycles de vie:

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

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

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

Les phases ont des objectifs à courir avant avant ou après post - phase a, 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 afficher les objectifs sous forme de phases "insérées" supplémentaires si vous le souhaitez. Lisez ici ou jetez un œil à la réponse @Gerolds pour plus de détails.

LifeCycle vs Phases: Life Cycle est une collection de fichiers phases. Lorsque vous appelez une phase, elle appellera également toutes les phases qui la précèdent. 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 déploiement)
2. Cycle de vie par défaut / build - cela gère le déploiement complet du projet
3. Cycle de vie du site - cela gère la génération de la documentation java du projet.

Le cycle de vie propre comprend 3 phases: pré-nettoyage, nettoyage et post-nettoyage. Les phases des cycles de vie par défaut et du site sont les mêmes que celles indiquées dans l'image.