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).
