From dd522ff10cd1f37acf2a04116d14516dcf81a3a5 Mon Sep 17 00:00:00 2001 From: Jason van Zyl Date: Sun, 13 Feb 2005 20:21:16 +0000 Subject: [PATCH] o little additions git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163353 13f79535-47bb-0310-9956-ffa450edef68 --- .../site/apt/lifecycle/lifecycle-phases.apt | 34 +++++++++++++------ 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/maven-core/src/site/apt/lifecycle/lifecycle-phases.apt b/maven-core/src/site/apt/lifecycle/lifecycle-phases.apt index 0c0c9d0865..82586a741e 100644 --- a/maven-core/src/site/apt/lifecycle/lifecycle-phases.apt +++ b/maven-core/src/site/apt/lifecycle/lifecycle-phases.apt @@ -40,11 +40,21 @@ Maven Lifecycle Phases * deploy -o phases are used as join points (before/around/after) -o mojos specify what phase they are contributing to -o use goal names to protect from changes in the goal specifics themselves -o the phases are really placeholders for various goals to be executed and it would be the phases that the user - could specify on the CLI so something like + Mojos only know what they need as input and what phase they contribute to perform their task. + They don't know anything about Maven specifically because Maven controls how they are executed in the lifecycle + using the lifecycle configuration which looks like the following: + ++-----+ + +%{snippet|id=lifecycle|url=http://cvs.apache.org/viewcvs.cgi/*checkout*/maven-components/maven-core/src/main/resources/META-INF/plexus/components.xml} + ++-----+ + + You can see that we use the mojo id to indicate what mojo we want to execute at a particular place in the lifecycle + to protected against any package refactoring and generally protects against any changes that might occur with + naming. + + An example of something commonly done is Maven is to compile the sources of your project: +-----+ @@ -54,18 +64,20 @@ m2 compile This would invoke the lifecycle up to, and including, the compile phase. - This may seem a bit lengthly but I think it covers anything that could possibly be done and there is enough flexibility - within the lifecycle to accommodate users i.e. we don't need to have a boundless set of lifecycle phases. What people - do in a project is, in fact, pretty limited. - - Using the lifecycle also makes it easier to call out to the artifact handlers. + What about mojos that fall outside of this standard lifecycle? Things like <<>>, <<>>, + and <<>>? These mojos can be executed by invoking Maven as such. +-----+ -%{snippet|id=lifecycle|url=http://cvs.apache.org/viewcvs.cgi/*checkout*/maven-components/maven-core/src/main/resources/META-INF/plexus/components.xml} +m2 : +-----+ + These mojos that execute can be thought of as stand-alone tools, they may require dependency resolution + but aside from that they do not interact with any other mojos + +Adding Mojos into the lifecycle + Here we are using antlr and it is known to maven that this plugin contributes to the generate-sources phase. In m1 the antlr plugin, in fact, worked by magic i.e. if there was a grammar present antlr would try to fire. This is a little too tricky and it would make sense to allow users to specify what they want fired as part of their