Les objectifs sont exécutés en phases qui aident à déterminer l'ordre dans lequel les objectifs doivent être exécutés. La meilleure compréhension de cela est de regarder les liaisons de cycle de vie Maven par défaut qui montrent quels objectifs sont exécutés dans quelles phases par défaut. Les objectifs de la phase de compilation seront toujours exécutés avant les objectifs de la phase de test qui seront toujours exécutés avant les objectifs de la phase de package et ainsi de suite.
Une partie de la confusion est exacerbée par le fait que lorsque vous exécutez maven, vous pouvez spécifier un objectif ou une phase. Si vous spécifiez une phase, maven exécutera toutes les phases jusqu'à la phase que vous avez spécifiée dans l'ordre (par exemple, si vous spécifiez le package, il passera d'abord par la phase de compilation, puis la phase de test et enfin la phase du package) et pour chaque phase, il sera exécuter tous les objectifs attachés à cette phase.
Lorsque vous créez une exécution de plugin dans votre fichier de construction Maven et que vous spécifiez uniquement l'objectif, il liera cet objectif à une phase par défaut donnée. Par exemple, l'objectif jaxb: xjc se lie par défaut à la phase de génération de ressources. Cependant, lorsque vous spécifiez l'exécution, vous pouvez également spécifier explicitement la phase pour cet objectif.
Si vous spécifiez un objectif lorsque vous exécutez Maven, il exécutera cet objectif et uniquement cet objectif. En d'autres termes, si vous spécifiez l'objectif jar: jar, il exécutera uniquement l'objectif jar: jar pour empaqueter votre code dans un jar. Si vous n'avez pas auparavant exécuté l'objectif de compilation ou préparé votre code compilé d'une autre manière, cela peut très probablement échouer.
J'ai pris l'habitude de dire "Maven passe toutes les phases (jusqu'à et y compris les données)" au lieu de "s'exécute" ou "exécute" (ce dernier comme on l'appelle dans l' introduction de Maven au cycle de vie de la construction ). Cela le distingue plus clairement du code du but qui est réellement exécuté. Mais cela pourrait être un goût personnel.
GeroldBroser réintègre Monica le
Mais nous pouvons également exécuter des objectifs qui n'appartiennent à aucune phase, c'est mvn archetype:generate-à- dire , et dans ce cas, maven exécute uniquement l'objectif?
Quazi Irfan
1
@Pace Avez-vous une référence pour le dernier paragraphe? J'ai douté de cela et je l'ai essayé avec un projet simple ici: mvn testruns:, --- maven-resources-plugin:2.6:resources ... --- maven-compiler-plugin:3.1:compile ... --- maven-resources-plugin:2.6:testResources ... --- maven-compiler-plugin:3.1:testCompile ... --- maven-surefire-plugin:2.12.4:testtandis que mvn compiler:testCompilejuste s'exécute --- maven-compiler-plugin:3.1:testCompile ....
GeroldBroser réintègre Monica le
4
@Pace mvn clean compiler:testCompiles'exécute --- maven-clean-plugin:2.5:clean ... --- maven-compiler-plugin:3.1:testCompileavec échec Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-cli) on project mvnphase: Compilation failure ... cannot find symbol ... symbol: variable MvnPhase(où MvnPhaseest la classe sous test référencée dans la classe de test). Apparemment, les phases ne sont pas invoquées si un objectif est invoqué explicitement.
GeroldBroser réintègre Monica le
1
Sur la base des contributions de geroldbroser et @ kekko12, j'ai mis à jour le dernier paragraphe pour indiquer que, lorsqu'un objectif est spécifié, seul cet objectif est exécuté, et pas toutes les phases précédentes.
Rendez-vous
188
Le cycle de vie est une séquence de phases nommées .
Les phases s'exécutent séquentiellement. Exécuter une phase signifie exécuter toutes les phases précédentes.
Le plugin est une collection d' objectifs également appelés MOJO ( M aven O ld J ava O bject).
Analogie: le plugin est une classe et les objectifs sont des méthodes au sein de la classe.
Maven est basé sur le concept central d'un Build Life Cycles . À l'intérieur de chaque cycle de vie de construction, il y a des phases de construction , et à l'intérieur de chaque phase de construction, il y a des objectifs de construction .
Nous pouvons exécuter une phase de construction ou un objectif de construction. Lors de l'exécution d'une phase de build, nous exécutons tous les objectifs de build au cours de cette phase de build. Les objectifs de build sont affectés à une ou plusieurs phases de build. Nous pouvons également exécuter un objectif de génération directement.
Il existe trois principaux cycles de vie de construction intégrés :
Par exemple, le defaultcycle de vie comprend les phases de construction suivantes :
◾validate - validate the project is correct and all necessary information is available
◾compile - compile the source code of the project
◾test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
◾package - take the compiled code and package it in its distributable format, such as a JAR.
◾integration-test - process and deploy the package if necessary into an environment where integration tests can be run
◾verify - run any checks to verify the package is valid and meets quality criteria
◾install - install the package into the local repository, for use as a dependency in other projects locally
◾deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
Donc, pour passer par les phases ci-dessus, il suffit d'appeler une commande:
mvn <phase> { Ex: mvn install }
Pour la commande ci-dessus, à partir de la première phase, toutes les phases sont exécutées séquentiellement jusqu'à la phase «install». mvnpeut exécuter un objectif ou une phase (ou même plusieurs objectifs ou plusieurs phases) comme suit:
mvn clean install plugin:goal
Cependant, si vous souhaitez personnaliser le préfixe utilisé pour référencer votre plugin, vous pouvez spécifier le préfixe directement via un paramètre de configuration sur le POM demaven-plugin-plugin votre plugin.
La plupart des fonctionnalités de Maven se trouvent dans des plugins. Un plugin fournit un ensemble d' objectifs qui peuvent être exécutés à l'aide de la syntaxe suivante:
mvn [plugin-name]:[goal-name]
Par exemple, un projet Java peut être compilé avec l'objectif de compilation du plug-in du compilateur en exécutant mvn compiler:compile.
Le cycle de vie de la construction est une liste de phases nommées qui peuvent être utilisées pour donner un ordre à l'exécution des objectifs.
Les objectifs fournis par les plugins peuvent être associés à différentes phases du cycle de vie. Par exemple, par défaut, l' objectifcompiler:compile est associé à la compilephase , tandis que l' objectifsurefire:test est associé à la testphase . Considérez la commande suivante:
mvn test
Lorsque la commande précédente est exécutée, Maven exécute tous les objectifs associés à chacune des phases jusqu'à et y compris la testphase. Dans un tel cas, Maven exécute le resources:resourcesbut associé à la process-resourcesphase, puis compiler:compile, et ainsi de suite jusqu'à ce qu'il exécute finalement le surefire:testbut.
Cependant, même si une phase de génération est responsable d'une étape spécifique du cycle de vie de la génération, la manière dont elle s'acquitte de ces responsabilités peut varier. Et cela se fait en déclarant les objectifs du plugin liés à ces phases de construction.
Un objectif de plugin représente une tâche spécifique (plus fine qu'une phase de build) qui contribue à la construction et à la gestion d'un projet. Il peut être lié à zéro ou plusieurs phases de construction. Un objectif non lié à une phase de génération peut être exécuté en dehors du cycle de vie de la génération par appel direct. L'ordre d'exécution dépend de l'ordre dans lequel le ou les objectifs et la ou les phases de génération sont invoqués. Par exemple, considérez la commande ci-dessous. Les arguments cleanet packagesont des phases de construction, tandis que le dependency:copy-dependenciesest un objectif (d'un plugin).
mvn clean dependency:copy-dependencies package
Si cela devait être exécuté, la cleanphase sera exécutée en premier (ce qui signifie qu'elle exécutera toutes les phases précédentes du cycle de vie propre, plus la cleanphase elle-même), puis l' dependency:copy-dependenciesobjectif, avant d'exécuter finalement la packagephase (et toutes ses phases de construction précédentes de le cycle de vie par défaut).
De plus, si un objectif est lié à une ou plusieurs phases de construction, cet objectif sera appelé dans toutes ces phases.
De plus, une phase de construction peut également avoir zéro ou plusieurs objectifs liés. Si une phase de construction n'a pas d'objectifs liés, cette phase de construction ne s'exécutera pas. Mais s'il a un ou plusieurs objectifs liés, il exécutera tous ces objectifs.
Liaisons de cycle de vie intégrées
Certaines phases ont des objectifs qui leur sont liés par défaut. Et pour le cycle de vie par défaut, ces liaisons dépendent de la valeur de l'emballage.
Si j'ai 2 profils, puis-je exécuter tous les plugins du profil 1 d'abord, puis celui du profil 2?
Bee
[plugin-name]dans l'exemple mvn [plugin-name]:[goal-name]est plutôt un préfixe de plugin . mvn clean installpeut non seulement " être utilisé dans un scénario multi-modules ". Le multi-module est un sujet totalement différent.
GeroldBroser réintègre Monica le
Les objectifs attachés à la même phase respectent-ils un ordre quelconque?
anguille ghEEz
5
La plupart de ce texte est copié textuellement de la documentation Maven . Cela doit être clairement indiqué!
Lii
source géniale!
Bobo
45
La réponse choisie est excellente, mais je voudrais quand même ajouter quelque chose de petit au sujet. Une illustration.
Il montre clairement comment les différentes phases sont liées à différents plugins et les objectifs que ces plugins exposent.
Examinons donc un cas d'exécution de quelque chose comme mvn compile:
C'est une phase qui exécute le plugin du compilateur avec un objectif de compilation
Le plugin du compilateur a des objectifs différents. Car mvn compileil est mappé à un objectif spécifique, l'objectif de compilation.
C'est la même chose que courir mvn compiler:compile
Par conséquent, la phase est composée d'objectifs de plugin .
Ressemble à une erreur d'illustration, merci de l'avoir remarquée (fondée sur le web).
Johnny
3
D'où avez-vous obtenu l'illustration? Avez-vous vérifié les droits d'auteur et les conditions d'utilisation?
Abdull
1
@Abdull image prise d'ici carminespagnuolo.eu/otheractivities/tutorato/PR-2014-2015/… (et elle apparaît également dans de nombreuses autres pages Web) en l'ajoutant à la réponse. Merci d'avoir soulevé ce point, n'était pas conscient de son importance.
Johnny
1
Les pointeurs des phases aux plugins dans le diagramme ne sont pas tout à fait correct non plus, le jarplugin s'exécute en fait dans la packagephase. Et le pom dans le sandwich entre les phases et les plugins est un peu déroutant (je suppose que cela devrait signifier que dans le pom vous pouvez configurer quels plugins s'exécutent dans quelles phases, en plus des liaisons par défaut). Mais le principe général est juste.
Maven définit 4 éléments d'un processus de construction:
Cycle de la vie
Trois intégrée des cycles de vie (aka cycles de vie de construction ): default, clean,site . ( Référence du cycle de vie )
Phase
Chaque cycle de vie est composé de phases , par exemple pour le defaultcycle de vie: compile, test, package,install , etc.
Brancher
Un artefact qui fournit un ou plusieurs objectifs.
En fonction du type d'emballage ( jar, warles objectifs de plugins, etc.) sont liés à des phases par défaut. ( Liaisons de cycle de vie intégrées )
Objectif
La tâche (action) qui est exécutée. Un plugin peut avoir un ou plusieurs objectifs.
Un ou plusieurs objectifs doivent être spécifiés lors de la configuration d'un plugin dans un POM . De plus, dans le cas où un plugin n'a pas de phase par défaut définie, le ou les objectifs spécifiés peuvent être liés à une phase.
Seules les phases du cycle de vie ont vraiment du sens pour être considérées comme des «étapes» (d'un processus de construction). Je préfère l'appeler 4 entités / éléments / choses .
GeroldBroser réintègre Monica le
Quand je vois le monde Build Phase, je le considère comme une autre phase d'un cycle de vie, et cela m'embrouille.
Quazi Irfan
26
Je crois qu'une bonne réponse est déjà prévu, mais je voudrais ajouter un schéma facile à suivre des différentes 3 cycles de vie ( build, cleanet site) et les phases de chacun.
Les phases en gras - sont les principales phases couramment utilisées.
En bref à partir du lien, vous ne devriez 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 Goal
1. Cycle de vie vs phase
Le cycle de vie est une collection de phases dans l'ordre voir ici les références de cycle de vie . Lorsque vous appelez une phase , elle appellera également toutes les phases avant elle.
Par exemple, le cycle de vie propre comporte 3 phases ( pré-nettoyage, nettoyage, post-nettoyage ).
mvn clean
Il appellera pré-nettoyer et nettoyer .
2. Plugin vs objectif
L'objectif est comme une action dans Plugin . Donc, si le plugin est une classe, l'objectif est une méthode.
vous pouvez appeler un objectif comme celui-ci:
mvn clean:clean
Cela signifie "appeler le but propre, dans le plugin propre" (Rien ne concerne la phase propre ici. Ne laissez pas le mot "propre" vous dérouter, ce ne sont pas les mêmes!)
3. Maintenant, la relation entre la phase et l'objectif:
La phase peut (pré) établir des liens 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 clean: clean.
Réponses:
Les objectifs sont exécutés en phases qui aident à déterminer l'ordre dans lequel les objectifs doivent être exécutés. La meilleure compréhension de cela est de regarder les liaisons de cycle de vie Maven par défaut qui montrent quels objectifs sont exécutés dans quelles phases par défaut. Les objectifs de la phase de compilation seront toujours exécutés avant les objectifs de la phase de test qui seront toujours exécutés avant les objectifs de la phase de package et ainsi de suite.
Une partie de la confusion est exacerbée par le fait que lorsque vous exécutez maven, vous pouvez spécifier un objectif ou une phase. Si vous spécifiez une phase, maven exécutera toutes les phases jusqu'à la phase que vous avez spécifiée dans l'ordre (par exemple, si vous spécifiez le package, il passera d'abord par la phase de compilation, puis la phase de test et enfin la phase du package) et pour chaque phase, il sera exécuter tous les objectifs attachés à cette phase.
Lorsque vous créez une exécution de plugin dans votre fichier de construction Maven et que vous spécifiez uniquement l'objectif, il liera cet objectif à une phase par défaut donnée. Par exemple, l'objectif jaxb: xjc se lie par défaut à la phase de génération de ressources. Cependant, lorsque vous spécifiez l'exécution, vous pouvez également spécifier explicitement la phase pour cet objectif.
Si vous spécifiez un objectif lorsque vous exécutez Maven, il exécutera cet objectif et uniquement cet objectif. En d'autres termes, si vous spécifiez l'objectif jar: jar, il exécutera uniquement l'objectif jar: jar pour empaqueter votre code dans un jar. Si vous n'avez pas auparavant exécuté l'objectif de compilation ou préparé votre code compilé d'une autre manière, cela peut très probablement échouer.
la source
mvn archetype:generate-à- dire , et dans ce cas, maven exécute uniquement l'objectif?mvn testruns:,--- maven-resources-plugin:2.6:resources ... --- maven-compiler-plugin:3.1:compile ... --- maven-resources-plugin:2.6:testResources ... --- maven-compiler-plugin:3.1:testCompile ... --- maven-surefire-plugin:2.12.4:testtandis quemvn compiler:testCompilejuste s'exécute--- maven-compiler-plugin:3.1:testCompile ....mvn clean compiler:testCompiles'exécute--- maven-clean-plugin:2.5:clean ... --- maven-compiler-plugin:3.1:testCompileavec échecFailed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-cli) on project mvnphase: Compilation failure ... cannot find symbol ... symbol: variable MvnPhase(oùMvnPhaseest la classe sous test référencée dans la classe de test). Apparemment, les phases ne sont pas invoquées si un objectif est invoqué explicitement.Maven est basé sur le concept central d'un Build Life Cycles . À l'intérieur de chaque cycle de vie de construction, il y a des phases de construction , et à l'intérieur de chaque phase de construction, il y a des objectifs de construction .
Nous pouvons exécuter une phase de construction ou un objectif de construction. Lors de l'exécution d'une phase de build, nous exécutons tous les objectifs de build au cours de cette phase de build. Les objectifs de build sont affectés à une ou plusieurs phases de build. Nous pouvons également exécuter un objectif de génération directement.
Il existe trois principaux cycles de vie de construction intégrés :
Chaque cycle de vie de construction est composé de phases
Par exemple, le
defaultcycle de vie comprend les phases de construction suivantes :Donc, pour passer par les phases ci-dessus, il suffit d'appeler une commande:
Pour la commande ci-dessus, à partir de la première phase, toutes les phases sont exécutées séquentiellement jusqu'à la phase «install».
mvnpeut exécuter un objectif ou une phase (ou même plusieurs objectifs ou plusieurs phases) comme suit:Cependant, si vous souhaitez personnaliser le préfixe utilisé pour référencer votre plugin, vous pouvez spécifier le préfixe directement via un paramètre de configuration sur le POM de
maven-plugin-pluginvotre plugin.Une phase de construction est composée d' objectifs de plugin
La plupart des fonctionnalités de Maven se trouvent dans des plugins. Un plugin fournit un ensemble d' objectifs qui peuvent être exécutés à l'aide de la syntaxe suivante:
Par exemple, un projet Java peut être compilé avec l'objectif de compilation du plug-in du compilateur en exécutant
mvn compiler:compile.Le cycle de vie de la construction est une liste de phases nommées qui peuvent être utilisées pour donner un ordre à l'exécution des objectifs.
Les objectifs fournis par les plugins peuvent être associés à différentes phases du cycle de vie. Par exemple, par défaut, l' objectif
compiler:compileest associé à lacompilephase , tandis que l' objectifsurefire:testest associé à latestphase . Considérez la commande suivante:Lorsque la commande précédente est exécutée, Maven exécute tous les objectifs associés à chacune des phases jusqu'à et y compris la
testphase. Dans un tel cas, Maven exécute leresources:resourcesbut associé à laprocess-resourcesphase, puiscompiler:compile, et ainsi de suite jusqu'à ce qu'il exécute finalement lesurefire:testbut.Cependant, même si une phase de génération est responsable d'une étape spécifique du cycle de vie de la génération, la manière dont elle s'acquitte de ces responsabilités peut varier. Et cela se fait en déclarant les objectifs du plugin liés à ces phases de construction.
Un objectif de plugin représente une tâche spécifique (plus fine qu'une phase de build) qui contribue à la construction et à la gestion d'un projet. Il peut être lié à zéro ou plusieurs phases de construction. Un objectif non lié à une phase de génération peut être exécuté en dehors du cycle de vie de la génération par appel direct. L'ordre d'exécution dépend de l'ordre dans lequel le ou les objectifs et la ou les phases de génération sont invoqués. Par exemple, considérez la commande ci-dessous. Les arguments
cleanetpackagesont des phases de construction, tandis que ledependency:copy-dependenciesest un objectif (d'un plugin).Si cela devait être exécuté, la
cleanphase sera exécutée en premier (ce qui signifie qu'elle exécutera toutes les phases précédentes du cycle de vie propre, plus lacleanphase elle-même), puis l'dependency:copy-dependenciesobjectif, avant d'exécuter finalement lapackagephase (et toutes ses phases de construction précédentes de le cycle de vie par défaut).De plus, si un objectif est lié à une ou plusieurs phases de construction, cet objectif sera appelé dans toutes ces phases.
De plus, une phase de construction peut également avoir zéro ou plusieurs objectifs liés. Si une phase de construction n'a pas d'objectifs liés, cette phase de construction ne s'exécutera pas. Mais s'il a un ou plusieurs objectifs liés, il exécutera tous ces objectifs.
Liaisons de cycle de vie intégrées
Certaines phases ont des objectifs qui leur sont liés par défaut. Et pour le cycle de vie par défaut, ces liaisons dépendent de la valeur de l'emballage.
Architecture Maven:
Référence 1
Référence 2
Exemple Eclipse pour Maven Lifecycle Mapping
la source
[plugin-name]dans l'exemplemvn [plugin-name]:[goal-name]est plutôt un préfixe de plugin .mvn clean installpeut non seulement " être utilisé dans un scénario multi-modules ". Le multi-module est un sujet totalement différent.La réponse choisie est excellente, mais je voudrais quand même ajouter quelque chose de petit au sujet. Une illustration.
Il montre clairement comment les différentes phases sont liées à différents plugins et les objectifs que ces plugins exposent.
Examinons donc un cas d'exécution de quelque chose comme
mvn compile:mvn compileil est mappé à un objectif spécifique, l'objectif de compilation.mvn compiler:compilePar conséquent, la phase est composée d'objectifs de plugin .
Lien vers la référence
la source
mvn testpointepackageetmvn installpointedeploy?jarplugin s'exécute en fait dans lapackagephase. Et le pom dans le sandwich entre les phases et les plugins est un peu déroutant (je suppose que cela devrait signifier que dans le pom vous pouvez configurer quels plugins s'exécutent dans quelles phases, en plus des liaisons par défaut). Mais le principe général est juste.Les définitions sont détaillées à la page du site Maven Introduction au cycle de vie de construction , mais j'ai essayé de résumer :
Maven définit 4 éléments d'un processus de construction:
Cycle de la vie
Trois intégrée des cycles de vie (aka cycles de vie de construction ):
default,clean,site. ( Référence du cycle de vie )Phase
Chaque cycle de vie est composé de phases , par exemple pour le
defaultcycle de vie:compile,test,package,install, etc.Brancher
Un artefact qui fournit un ou plusieurs objectifs.
En fonction du type d'emballage (
jar,warles objectifs de plugins, etc.) sont liés à des phases par défaut. ( Liaisons de cycle de vie intégrées )Objectif
La tâche (action) qui est exécutée. Un plugin peut avoir un ou plusieurs objectifs.
Un ou plusieurs objectifs doivent être spécifiés lors de la configuration d'un plugin dans un POM . De plus, dans le cas où un plugin n'a pas de phase par défaut définie, le ou les objectifs spécifiés peuvent être liés à une phase.
Maven peut être invoqué avec:
clean,package)<plugin-prefix>:<goal>(par exempledependency:copy-dependencies)<plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>(par exempleorg.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile)avec une ou plusieurs combinaisons de tout ou partie, p.ex.:
la source
Build Phase, je le considère comme une autre phase d'un cycle de vie, et cela m'embrouille.Je crois qu'une bonne réponse est déjà prévu, mais je voudrais ajouter un schéma facile à suivre des différentes 3 cycles de vie (
build,cleanetsite) et les phases de chacun.Les phases en gras - sont les principales phases couramment utilisées.
la source
generate-resourcesapparaît deux fois etgenerate-sourcesest manquant.Nous remercions Sandeep Jindal et Premraj. Leur explication m'aide à comprendre après une confusion à ce sujet pendant un certain temps.
J'ai créé quelques exemples de code complet 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.
En bref à partir du lien, vous ne devriez pas essayer de comprendre les trois à la fois, vous devez d'abord comprendre la relation dans ces groupes:
1. Cycle de vie vs phase
Le cycle de vie est une collection de phases dans l'ordre voir ici les références de cycle de vie . Lorsque vous appelez une phase , elle appellera également toutes les phases avant elle.
Par exemple, le cycle de vie propre comporte 3 phases ( pré-nettoyage, nettoyage, post-nettoyage ).
Il appellera pré-nettoyer et nettoyer .
2. Plugin vs objectif
L'objectif est comme une action dans Plugin . Donc, si le plugin est une classe, l'objectif est une méthode.
vous pouvez appeler un objectif comme celui-ci:
Cela signifie "appeler le but propre, dans le plugin propre" (Rien ne concerne la phase propre ici. Ne laissez pas le mot "propre" vous dérouter, ce ne sont pas les mêmes!)
3. Maintenant, la relation entre la phase et l'objectif:
La phase peut (pré) établir des liens avec un ou plusieurs objectifs . Par exemple, normalement, la phase propre est liée à l'objectif propre. Ainsi, lorsque vous appelez cette commande:
Il appellera la phase de pré-nettoyage et la phase de nettoyage qui est liée à l'objectif clean: clean.
C'est presque la même chose que:
Plus de détails et d'exemples complets sont dans https://www.surasint.com/maven-life-cycle-phase-and-goal-easy-explained/
la source
Terminologie de travail Maven ayant des phases et des objectifs.
Phase: la phase Maven est un ensemble d'actions associé à 2 ou 3 objectifs
exmaple: - si vous exécutez mvn clean
c'est la phase qui exécutera l'objectif mvn clean: clean
But: but Maven délimité par la phase
pour référence http://books.sonatype.com/mvnref-book/reference/lifecycle-sect-structure.html
la source
Il existe trois cycles de vie de construction intégrés:
Cycle de vie par défaut -> [valider, initialiser, générer-sources, processus-sources, générer-ressources, processus-ressources, compiler, classes-processus, générer-tester-sources, processus-tester-sources, générer-tester-ressources, processus -test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy]
Cycle de vie propre -> [pré-nettoyage, nettoyage, post-nettoyage]
Site du cycle de vie -> [pré-site, site, post-site, site-déploiement]
Le flux est séquentiel, par exemple, pour le cycle de vie par défaut , il commence par valider , puis initialiser et ainsi de suite ...
Vous pouvez vérifier le cycle de vie en activant le mode de débogage, par
mvnexemple,mvn -X <your_goal>la source