Phases, goals and plugins
1. A Build Lifecycle consists of Phases
Clean Lifecycle - ALL phases:
- pre-clean
- clean
- post-clean
Default Lifecycle (Build phases) - ALL phases:
- validate
- initialize
- generate-sources
- process-sources
- generate-resources
- process-resources
- compile
- process-classes
- generate-test-sources
- process-test-sources
- generate-test-resources
- process-test-resources
- test-compile
- process-test-classes
- test
- prepare-package
- package
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install
- deploy
Running mvn deploy will execute all preceding phases such as validate, compile, package, etc
2. A Build Phase consists of Goals
A goal represents a specific task
Ej. mvn clean dependency:copy-dependencies package
The clean phase will be executed first and then the dependency:copy-dependencies goal, before finally executing the package phase (and all its preceeding build phases of the default lifecycle)
Some phases have goals binded to them by default and for the default lifecycle, these bindings depend on the packaging value:
Clean Lifecycle Bindings (only the most used):
clean
=> clean:clean
Default Lifecycle Bindings (only the most used):
process-resources
=> resources:resources
compile
=> compiler:compile
process-test-resources
=> resources:testResources
test-compile
=> compiler:testCompile
test
=> surefire:test
package
=> ejb:ejb or ejb3:ejb3 or jar:jar or par:par or rar:rar or war:war
install
=> install:install
deploy
=> deploy:deploy
3. Setting Up Your Project to Use the Build Lifecycle
3.1 The first, and most common way, is to set the packaging for your project via the equally named POM element <packaging> (jar, war, ear and pom)
Each packaging contains a list of goals to bind to a particular phase
3.2 The second way to add goals to phases is to configure plugins in your project
Plugins are artifacts that provide goals to Maven. A plugin may have one or more goals.
There are Maven plugins for building, testing, source control management, running a web server, generating Eclipse project files, etc.
Plugins are introduced and configured in a <plugins>-section of a pom.xml
For example, the Modello plugin binds by default its goal modello:java to the generate-sources phase
(Note: The modello:java goal generates Java source codes).
So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the <plugins> section of <build>:
...
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<configuration>
<models>
<model>src/main/mdo/maven.mdo</model>
</models>
<version>4.0.0</version>
</configuration>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
...
Now, in the case of modello:java, it only makes sense in the generate-sources phase. But some goals can be used in more than one phase, and there may not be a sensible default
For example, let's say you have a goal display:time that echos the current time to the commandline, and you want it to run in the process-test-resources phase to indicate when the tests were started. This would be configured like so:
...
<plugin>
<groupId>com.mycompany.example</groupId>
<artifactId>display-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>process-test-resources</phase>
<goals>
<goal>time</goal>
</goals>
</execution>
</executions>
</plugin>
...
A plugin provides a set of goals that can be executed using the following syntax:
Los Goals de Maven son las unidades mínimas de ejecución de las que disponemos durante su uso.. Un grupo de goals conforman un plugin. La ejecución de un goal se dispara desde línea de comandos invocando Maven con el nombre del plugin que lo contiene:
mvn [plugin-name]:[goal-name]
Otra forma de invocar un goal es indirectamente. Maven lo invocará dependiendo de la fase del ciclo de vida cuando por ejemplo se ejecute
mvn compile
Ver:
http://www.dosideas.com/wiki/Maven
Summary:
Goals provided by plugins can be associated with different phases of the lifecycle. For example, by default, the goal "compiler:compile" is associated with the compile-phase, while the goal "surefire:test" is associated with the test-phase.
When the command "mvn test" is executed, Maven will run all the goals associated with each of the phases up to the test-phase. So it will run the "resources:resources"-goal associated with the process-resources-phase, then "compiler:compile", and so on until it finally runs the "surefire:test"-goal.
When we executed mvn install, Maven executes all phases up to the install phase, and in the process of stepping through the lifecycle phases it executes all goals bound to each phase.
Instead of executing a Maven lifecycle goal you could achieve the same results by specifying a sequence of plugin goals as follows:
mvn resources:resources \
compiler:compile \
resources:testResources \
compiler:testCompile \
surefire:test \
jar:jar \
install:install
Is much easier to execute lifecycle phases than it is to specify explicit goals on the command line
The Archetype plugin created a project with a file named pom.xml.
This is the Project Object Model (POM), a declarative description of a project.
When Maven executes a goal, each goal has access to the information defined in a project’s POM. When the jar:jar goal needs to create a JAR file, it looks to the POM to find out what the JAR file’s name is. When the compiler:compile goal compiles Java source code into bytecode, it looks to the POM to see if there are any parameters for the compile goal. Goals execute in the context of a POM
Dependencies:
When you run Maven for the first time, you will notice that Maven downloads a number of files from a remote Maven repository.
If the simple project was the first time you ran Maven, the first thing it will do is download the latest release of the Resources plugin when it triggers the resources:resource goal.
In Maven, artifacts and plugins are retrieved from a remote repository when they are needed.
One of the reasons the initial Maven download is so small (1.5 MiB) is due to the fact that Maven doesn’t ship with much in the way of plugins.
Maven ships with the bare minimum and fetches from a remote repository when it needs to. Maven ships with a default remote repository location (http://repo1.maven.org/maven2) which it uses to download the core Maven plugins and dependencies.
The example section hinted at Maven's dependency-handling mechanism. A project that needs the Hibernate-library simply has to declare Hibernate's project coordinates in its POM. Maven will automatically download the dependency and the dependencies that Hibernate itself needs (called transitive dependencies) and store them in the user's local repository. Maven 2 Central Repository[3] is used by default to search for libraries, but one can configure the repositories used (e.g. company-private repositories) in POM.
There are search engines such as Maven Central, which can be used to find out coordinates for different open-source libraries and frameworks.
Links:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference
http://en.wikipedia.org/wiki/Apache_Maven
http://www.sonatype.com/books/mvnex-book/reference/simple-project-sect-simple-core.html
