Maven build lifecycles, phases, plug-ins and goals

Source

Maven default bindings

Source: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in_Lifecycle_Bindings

Each phase of a build lifecycle in implemented by a set of goals. These goals are part of plugins.

Which goals handle which phases is specified by binding the goals(s) to phases. Following is the list of default such bindings.

Some phases have goals binded to them by default. And for the default lifecycle, these bindings depend on the packaging value. Here are some of the goal-to-build-phase bindings.

Clean Lifecycle Bindings

clean

clean:clean

Default Lifecycle Bindings - Packaging ejb / ejb3 / jar / par / rar / war

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

Default Lifecycle Bindings - Packaging ear

generate-resources	ear:generateApplicationXml
process-resources	resources:resources
package	ear:ear
install	install:install
deploy	deploy:deploy

Default Lifecycle Bindings - Packaging maven-plugin

generate-resources	plugin:descriptor
process-resources	resources:resources
compile	compiler:compile
process-test-resources	resources:testResources
test-compile	compiler:testCompile
test	surefire:test
package	jar:jar and plugin:addPluginArtifactMetadata
install	install:install and plugin:updateRegistry
deploy	deploy:deploy

Default Lifecycle Bindings - Packaging pom

package	site:attach-descriptor
install	install:install
deploy	deploy:deploy

Site Lifecycle Bindings

site	site:site
site-deploy	site:deploy

 

Phases of the maven lifecycles

Source: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

Clean Lifecycle

pre-clean	executes processes needed prior to the actual project cleaning
clean	remove all files generated by the previous build
post-clean	executes processes needed to finalize the project cleaning

Default Lifecycle

validate	validate the project is correct and all necessary information is available.
initialize	initialize build state, e.g. set properties or create directories.
generate-sources	generate any source code for inclusion in compilation.
process-sources	process the source code, for example to filter any values.
generate-resources	generate resources for inclusion in the package.
process-resources	copy and process the resources into the destination directory, ready for packaging.
compile	compile the source code of the project.
process-classes	post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources	generate any test source code for inclusion in compilation.
process-test-sources	process the test source code, for example to filter any values.
generate-test-resources	create resources for testing.
process-test-resources	copy and process the resources into the test destination directory.
test-compile	compile the test source code into the test destination directory
process-test-classes	post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test	run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package	perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package	take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test	perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test	process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test	perform actions required after integration tests have been executed. This may including cleaning up the environment.
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.

Site Lifecycle

pre-site	executes processes needed prior to the actual project site generation
site	generates the project's site documentation
post-site	executes processes needed to finalize the site generation, and to prepare for site deployment
site-deploy	deploys the generated site documentation to the specified web server

 

Nice maven article

http://blogs.plexibus.com/2007/12/02/maven-guide-part-one-basics/

Creating a empty maven project structure

Maven can itself create empty project structures when you want to start a new code base. To create an empty project structure, maven needs to be told the kind of project (simple servlet web application or JSF web application with Spring and hibernate or Web application with spring, hibernate and spring MVC etc…). Maven knows the details of the directory structure for each project type through an archetype. So a simple servlet web application will have its own archetype that details how the directory structure of a simple servlet web application looks like.

 

So to start with execute

 

mvn archetype:generate

 

Then Maven will ask you the kind of project you want to create by listing the archetype that it knows about and asking you to select the archetype. Then it wail ask other details about your project (group id, artifact id etc… ) and after all project details are provided, will create the empty project structure for you.

 

Source

Running a Single JUnit test class in maven

mvn test -Dtest=StudentServiceTest. Details

The Maven build cycle

Maven Basics

This post is based on this serverside article.

The basic concept of Maven is a project. A project can create only one artifact. E.g. a web project can create a war file as an artifact. To work around this restriction of one artifact per project, a project can have sub-projects. Each of the sub-projects can have a artificat by themselves. The project's responsibility now is to take the sub-project's artifacts and make one artifact.

A project is defined as any directory with a project.xml in it. If sub-directories of a project directory have project.xml then they are project directories too.

All project artifacts (artifacts resulting from projects) are stored in repositories. There are remote and local repositories. Local repository is created in ./maven/repository. In windows its "c:/Documents and Settings/. In maven dependencies are expressed between artifacts. Like to create the artificat my_application.war, there is a dependency on version 1.0.2 of commons-logging. This dependency specification is laid out in project.xml. When maven is executed, it reads the project.xml, finds that you depend on commons-logging, picks up the specified version of commons-logging from the remote repository and dump it into the local repository and the version in the local repository is used to build your project's artifact (war in this case).
The structure of repository on a windows box:
//jars/.
c:/Documents and Settings/babu.subburathinam/maven/repository/commons-loggging/jars/commons-logging-1.0.7.jar

Instead of each project having a copy of its dependencies, all libraries are lodged in a repository and all projects share the libraries available in the repository. Each project will inturn publish its artifact on to the repository. This process of a project publishing its artifact is called "install"ing in maven lingo. This process of each project publishing its (snapshot and release) artifacts to a central repository helps in continuous integration. This is how: Daemon processes running in build servers can build each project with its updated dependencies several times a day, deploy and test the built artifacts. Thus, integration issues if any will surface much before the release date of a specific project.

Inputs to maven:
One of the input files to maven is Project Object Model (POM) file. This file describes the project to maven. This file has the following structure:

01
02
03 3
04 Sample-Maven-Project
05 sample-project
06 1.1
07 Sample Maven Project
08
09
10
11
12
13
14
15
16
17

Line 2 - Root element of XML
Line 3 - This tag is unused but needed.
Line 4 - A directory with this name is created in Maven repository to hold the artifacts of projects sharing the group id.
Line 5,6 - The id and version is used to create the artifact name as -.jar
Line 7 - Name of the project

The project Management section has project information such as the organization, its web site, location of SCM (Software configuration management), deployment and issue tracking sites, developer lists, mailing lists, etc...Most of this section is optional. The contents of project.xml can be extended. Most of the content is defined at the enterprise level and each project can override what is appropriate to it.
An example of the project management section:
01
02 Foobar Travels
03 http://www.foobar.com
04 http://www.foobar.com/logo.jpg
05
06
07 2003
08 foobar.blah.*
09 http://www.foobar.com/project-logo.jpg |
10 Project description goes here
11 Short Description
12 http://www.foobar.com
13 http://jira.foobar.com
14 http://staging.foobar.com
15 /etc/staging
16 /etc/builds
17
18
19 cvs:pserver:anon@foobar.com:/foo
20 http://scm.foobar.com
21
22
23
24
25 Dev List
26 subscribe-dev@foobar.com
27 unsubscribe-dev@foobar.com
28
29 ...
30 ...
31
32
33
34
35 Srikanth Shenoy
36 shenoy
37 srikanth@srikanth.org
38
39 ...
40 ...
41

* Lines 01-05 - Organization details
* Line 08 - Top level package for the project
* Line 09 - Project Logo
* Line 12 - Project web site
* Line 14 - The site where the project is hosted
* Line 15 - Physical location of project deployment
* Line 16 - Physical location where the project distributions are available
* Lines 18-21 - SCM to access the project source
* Lines 23-31 - Mailing list for the project
* Lines 33-41 - Developers in the project


General structure of a maven project:

Maven Project Root
- maven.xml // Project definition file
- src // source directory
-- conf // Configuration within source
---xyz.properties // config gile
--java // java source
---com
----access
-----dev
------Hello.java
- test // test directory
-- conf // test configuration
---abc.properties // test config file
--java // java test files
---com
----access
-----dev
------TestHello.java

Project dependency section

In this section the project indicates all the dependecies that it has on artifacts of other projects. An example:

01
02
03 BeanUtils
04 commons-beanutils
05 1.5
06

commons-logging
commons-logging
1.0.3


castor
castor
0.9.4.3



Line 1 - Starts the dependencies
Line 3 - The artifact that this project depends on is at the directory named "BeanUtils" in the repository
Line 4,5 - The artifact name is "commons-beanutils-1.5.jar" (using -.jar)

Project build section

This section indicates the location of source, test and resource files. This is defined at the org. level or main project level for sub-projects to follow. If this section is not specified, no build ever gets done. Once build is over, all unit tests specified in the unit test section are executed. The contents of this section should match the actual layout of the code in the filesystem.

01
02 srikanth@srikanth.org
03 ${basedir}/src/java
04 ${basedir}/test/java
05
06
07 **/*Test.java
08
09
10
11
12
13 ${basedir}/src/conf
14
15 *.properties
16
17
18
19



* Line 02 - Email address to send notification about the build status
* Line 03 - Folder containing the source files for the project. The source can be java, jsp and so on.
* Line 04 - Directory containing the unit test files for the project.
* Lines 05-09 - The test file name pattern to run after the build is completed
* Lines 11-19 - Resources to be copied in case a jar is created.

Project reports sections
Once build is done, reports and documentation about the build are generated.
e.g.


maven-changes-plugin
maven-jdepend-plugin
maven-checkstyle-plugin
maven-pmd-plugin
maven-junit-report-plugin
maven-clover-plugin
maven-changelog-plugin
maven-file-activity-plugin
maven-developer-activity-plugin
maven-file-activity-plugin
maven-license-plugin
maven-linkcheck-plugin
maven-jxr-plugin