3.

Cycle de vie et goal Maven

Maven a pour objectif de grer tout le cycle de vie de l'application. Il dfinit pour cela une liste d'tapes ordonnes qui sont pour lui le cycle de vie par dfaut d'un projet. Chaque type de projets (jar, war...) pourra associer des actions diffrentes pour chaque tape. Le cycle de vie par dfaut dfinit les tapes suivantes :

validate Valide que le projet est correctement dfini compile Compile les sources test Lance les tests unitaires package Prpare la distribution du projet. (archives Jar, War, Ear...) integration-test Lance les tests d'intgration verify Lance des tests de validation du package cr. install Installe le package en local sur la machine pour pouvoir tre rutilis comme dpendance. deploy Dploie le package sur un serveur pour qu'il puisse tre rutilis par tout le monde. Un projet est un artifact dans Maven, il s'agit de la brique de base que manipule Maven. Pour dmarrer un pom, il faut au moins dfinir l'identification de l'artifact du projet. La dfinition complte d'un artifact est donne plus loin. Le fichier pom.xml minimaliste ressemblera donc ceci : Le premier pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.developpez</groupId> <artifactId>cours-maven-example</artifactId> <packaging>jar</packaging> <name>Projet d'exemple pour le cours Maven</name> <version>1.0</version> </project>

Local Repositories This folder contains your local Maven repository which is stored in ~/.m2/repository by default. It also contains a repository that represents the Maven projects contained in your Eclipse workspace. Global Repositories

This folder contains any global Maven repositories that are referenced by all Maven projects. This folder contains the Central Maven repository under the repository identifier of "central". It will also contain mirrors that have been configured in your Maven Settings (~/.m2/settings.xml). Project Repositories This folder contains repositories which are defined by your projects. These repositories are present either in your project's pom.xml file or in an active Maven Profile.

Project co-ordinates
Project co-ordinates are the minimal basic fields that a POM definition must contain. The three co-ordinate fields are groupId, artifactId, and version. These three fields mark a specific location within the repository, hence the term co-ordinates.

Sections of the POM

The previously displayed sample POM contains four major sections. They are explained as follows: fThe basics: This section contains project co-ordinates, dependency management, and inheritance details. Additionally, it also contains modules and project level properties. fBuild settings: This section contains the build details. fProject metadata: This section contains project-specific details such as name, organization, developers, URL, inception year, and so on. fEnvironment: This section contains all information regarding the environment including details of the version control being, issue management, continuous integration, mailing lists, repositories, and so on

Understanding the build lifecycle

The build lifecycle explicitly defines the process of building, testing, distributing an artifact, and is at the heart of every Maven project. There are three inbuilt build lifecycles: default, clean, and site.

Understanding the build lifecycle

The build lifecycle explicitly defines the process of building, testing, distributing an artifact, and is at the heart of every Maven project. There are three inbuilt build lifecycles: default, clean, and site.

Default lifecycle
The default lifecycle handles the project compilation, test, and deployment. While it contains over 20 build phases, the following are the most important phases:

fValidate: validates that all project information is available and is correct fCompile: compiles the source code fTest: runs unit tests within a suitable framework fPackage: packages the compiled code in its distribution format fIntegration-test: processes the package in the integration-test environment fVerify: runs checks to verify that the package is valid fInstall: installs the package in the local repository fDeploy: installs the final package in a remote repository

Clean lifecycle
The clean lifecycle handles the project cleaning and contains the following build phases: fPre-clean: executes processes required before project cleaning fClean: removes all files generated by previous builds fPost-clean: executes processes required to finalize project cleaning

Site lifecycle
The site lifecycle handles the generation and deployment of the projects site documentation:

Build profiles :
are specifications made in the POM and can be triggered as and when required. Some ways to trigger profiles are: fExplicit command-line trigger fMaven settings trigger fEnvironment specific trigger

Build automation
Build automation is the scripting of tasks that software developers have to do on a day-to-day basis. These tasks include: fCompilation of source code to binary code fPackaging of binary code fRunning tests fDeployment to remote systems fCreation of documentation and release notes

Build automation offers a range of benefits including speeding up of builds, elimination of

bad builds, standardization in teams and organizations, increased efficiency, and improvements in product quality. Today, it is considered as an absolute essential for software engineering practitioners.

 Project modularization
Considering that you're building a large enterprise application, it will need to interact with a legacy database, work with existing services, provide a modern web and device capable user interface, and expose APIs for other applications to consume. It does make sense to split this rather large project into subprojects or modules. Maven Multi-modular projects. Multi-modular projects consist of a "Parent Project" which contains "Child Projects" or "Modules". The parent project's POM file contains references to all these sub-modules. Each module can be of a different type, with a different packaging value

Apache Maven provides impeccable support for such a project organization through Apache

Dependency management :
Dependencies for Apache Maven projects are described in project POM files. While we take a closer look at these in the How it works... section of this recipe, here we will explore the Apache Maven dependency plugin. According to http://maven.apache.org/plugins/maven-dependency-plugin/: "The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location." It's a decent little plugin and provides us with a number of very useful goals. They are as follows:
$ mvn dependency:analyze Analyzes dependencies (used, unused, declared, undeclared) $ mvn dependency:analyze-duplicate Determines duplicate dependencies $ mvn dependency:resolve Resolves all dependencies $ mvn dependency:resolve-plugin Resolves all plugins $ mvn dependency:tree Displays dependency trees ***Maven dependencies have six possible scopes:

fCompile: This is the default scope. Compile dependencies are available in the classpaths. fProvided: This scope assumes that the JDK or the environment provides dependencies at runtime. fRuntime: Dependencies that are required at runtime and are specified in the runtime classpaths. fTest: Dependencies required for test compilation and execution.

fSystem: Dependency is always available, but the JAR is provided nonetheless. (avoid it it kills mavens porpose)
fImport: Imports dependencies specified in POM included via the <dependencyManagement/> element.

Source code quality checks

Getting ready
The Apache Maven PMD plugin automatically runs the PMD code analysis tool on the source code and generates a site report with results. In a typical configuration, the build fails if PMD detects quality issues in the source. This plugin introduces four goals: fpmd:pmd creates a PMD site report based on the rulesets and configuration set in the plugin fpmd:cpd generates a report for PMD's Copy/Paste Detector (CPD) tool fpmd:check verifies that the PMD report is empty and fails the build if it is not fpmd:cpd-check verifies that the CPD report is empty and fails the build if it is not