Maven for eXo VN

Apache Maven @ eXo Platform Hanoï – 09 Feb 2010

Arnaud Héritier eXo Platform

Software Factory Manager

Licensed under a Creative Commons license

OVERVIEW Apache Maven


BASICS Apache Maven

3


Definition ●  Apache Maven is a software project management

and comprehension tool. ●  Based on the concept of a project object model

(POM), Maven can manage a project's build, binaries, reporting and documentation from a central piece of information.

●  Apache Maven is a command line tool with some IDE integrations.


Conventions ●  1 project = 1 artifact (pom, jar, war, ear, …)

●  Standardized -  directories layout -  project descriptor (POM) -  build lifecycle

5


POM ●  An XML file (pom.xml)

●  Describing -  Project identification -  Project version -  Project description -  Build settings -  Dependencies -  …

<?xml version="1.0" encoding="UTF-8"?>!

<project>!

<modelVersion>4.0.0</modelVersion>!

<groupId>org.apache.maven</groupId>!

<artifactId>webapp-sample</artifactId>!

<version>1.1-SNAPSHOT</version>!

<packaging>war</packaging>!

<name>Simple webapp</name>!

<inceptionYear>2007</inceptionYear>!

<dependencies>!

<dependency>!

<groupId>org.springframework</groupId>!

<artifactId>spring-struts</artifactId>!

<version>2.0.2</version>!

</dependency>!

...!

</dependencies>!

</project>!


Without Maven With Maven

Dependencies


Dependencies ●  Declaratives

-  groupId + artifactId + version (+ classifier) -  Type (packaging) : jar, war, pom, ear, …

●  Transitives -  Lib A needs Lib B -  Lib B needs Lib C -  Thus Lib A needs Lib C


Dependencies ●  Scope

-  Compile (by default) : Required to build and run the application

-  Runtime : not required to build the application but needed at runtime

●  Ex : taglibs -  Provided : required to build the application but not

needed at runtime (provided by the container) ●  Ex : Servlet API, Driver SGBD, …

-  Test : required to build and launch tests but not needed by the application itself to build and run

●  Ex : Junit, TestNG, DbUnit, … -  System : local library with absolute path

●  Ex : software products


Dependencies ●  Define all dependencies you are using

-  and no more ! ●  Cleanup your dependencies with

-  mvn dependency:analyze!

●  Study your dependencies with -  mvn dependency:tree!-  mvn dependency:list!


Artifact Repository ●  By default :

-  A central repository ●  http://repo1.maven.org/

maven2 ●  Several dozen of Gb of OSS

libraries -  A local repository

●  ${user.home}/.m2/repository ●  All artifacts

-  Used by maven and its plugins

-  Used by your projects (dependencies)

-  Produced by your projects


Artifact Repository ●  By default Maven

downloads artifacts required by the project or itself from central

●  Downloaded artifacts are stored in the local repository


Versions ●  Project and dependency versions ●  Two different version variants -  SNAPSHOT version

●  The version number ends with –SNAPSHOT ●  The project is in development ●  Deliveries are changing over the time and are overridden

after each build ●  Artifacts are deployed with a timestamp on remote

repositories -  RELEASE version

●  The version number doesn’t end with –SNAPSHOT ●  Binaries won’t change


Versions


Versions ●  About SNAPSHOT dependencies

-  Maven allows the configuration of an update policy. The update policy defines the recurrence of checks if there is a new SNAPSHOT version available on the remote repository :

●  always ●  daily (by default) ●  interval:X (a given period in minutes) ●  never

-  Must not be used in a released project ●  They can change thus the release also ●  The release plugin will enforce it


Versions ●  Use the versions plugin to update all versions in all

POMs -  mvn versions:set \ –DnewVersion=A.B.C-SNAPSHOT!


Profiles

mvn <phases or goals> !

-PprofileId1,-profileId2 !

-P!profileId3!

●  Allow to modify the default behavior of Maven by overriding/adding some settings

●  Use mvn help:active-profiles to debug ●  Explicit activation or deactivation


Profiles

<settings>! ...! <activeProfiles>! <activeProfile>profile-1</activeProfile>! </activeProfiles>! ...!</settings>!

●  activeByDefault = If no other profile is activated ●  Activation through Maven settings


Profiles

<profiles>!

<profile>!

<activation>!

<property>!

<name>!skip-enforce</name>!

</property>!

</activation>!

...!

</profile>!

</profiles>!

<profiles>!

<profile>!

<activation>!

<property>!

<name>run-its</name>!

<value>true</value>!

</property>!

</activation>!

...!

</profile>!

</profiles>!

●  Activation based on environment variables


Profiles

<profiles>!

<profile>!

<activation>!

<os>!

<name>Windows XP</name>!

<family>Windows</family>!

<arch>x86</arch>!

<version>5.1.2600</version>!

</os>!

</activation>!

...!

</profile>!

</profiles>!

<profiles>!

<profile>!

<activation>!

<jdk>[1.3,1.6)</jdk>!

</activation>!

...!

</profile>!

</profiles>!

●  OS / Java settings


Profiles

<profiles>!

<profile>!

<activation>!

<file>!

<missing>${project.build.directory}/generated-sources/axistools/wsdl2java/org/apache/maven</missing>!

</file>!

</activation>!

...!

</profile>!

</profiles>!

●  Activation on present or missing files


Reactor pom.xml : <modules>

<module>moduleA</module>

<module>moduleC</module>

<module>moduleB</module>

</modules>

●  Ability of Maven to build several sub-modules resolving the order of their dependencies

●  Modules have to be defined in the POM -  For a performance reasons


Inheritence ●  Share settings between

projects/modules ●  Project

-  Business1 ●  Jar ●  War

-  Business2 ●  Jar ●  War

●  By default the parent project is supposed to be in the parent directory (../)

pom.xml for module Jar1 <parent>

<groupId>X.Y.Z</groupId>

<artifactId>jars</artifactId>

<version>1.0-SNAPSHOT<version>

</parent>


Build Lifecycle And Plugins ●  Plugin based architecture

for a great extensibility ●  Standardized lifecycle to

build all types of archetypes


GOOD & BAD PRACTICES Apache Maven


KISS Apache Maven


K.I.S.S. ●  Keep It Simple, Stupid ●  Start from scratch

-  Do not copy/paste what you find without understanding ●  Use only what you need

-  It’s not because maven offers many features that you need to use them

●  Filtering ●  Modules ●  Profiles ●  …


PROJECT ORGANIZATION GOOD & BAD PRACTICES

Apache Maven


Project bad practices ●  Ignore Maven conventions

-  Except if your are migrating from something else and the target has to be to follow them.

-  Except if they are not compatible with your IDE ●  Different versions in sub-modules

-  In that case they are standalone projects. ●  Too many inheritance levels

-  It makes the POMs maintenance more complex -  Where should I set this plugin parameter ? In which parent ?


Project bad practices ●  Have too many modules

-  Is there a good reason ? ●  Technical constraint ? ●  Team organization ?

-  It increases the build time ●  Many more artifacts to generate ●  Dependencies resolution more complex

-  It involves more complex developments ●  More modules to import in your IDE ●  More modules to update …


Project good practices ●  Use the default

inheritance : -  The reactor project is also

the parent of its modules. -  Configuration is easier :

●  No need to redefine SCM settings, site distribution settings …


POM GOOD & BAD PRACTICES Apache Maven


POM bad practices ●  Dependencies :

-  DON’T confuse dependencies and dependencyManagement

●  Plugins : -  DON’T confuse plugins and pluginManagement -  DON’T use AntRun plugin everywhere -  DON’T let Maven choose plugins versions for you


POM bad practices ●  Profiles :

-  DON’T create environment dependant builds -  DON’T rely on dependencies coming from profiles

(there is no transitive activation of profiles) ●  Reporting and quality

-  DON’T activate on an existing project all reports with default configuration

-  DON’T control formatting rules without giving settings for IDEs.

●  DON’T put everything you find in your POM.


POM good practices ●  Set versions of dependencies in project parent’s

dependencyManagement ●  Set dependencies (groupId, artifactId, scope) in

each module they are used ●  Use the dependency plugin (from apache) and

versions plugin (from mojo) to analyze, cleanup and update your dependencies.


DEVELOPMENT GOOD & BAD PRACTICES

Apache Maven


Development bad practices ●  DON’T spend your time in the terminal, ●  DON’T exchange libraries through emails, ●  DON’T always use "-Dmaven.test.skip=true” ●  DON’T manually do releases


Development good practices ●  Keep up-to-date your version of Maven

-  For example in 2.1 the time of dependencies/modules resolution decreased a lot (Initialization of a project of 150 modules passed from 8 minutes to less than 1)

●  Use the reactor plugin (Maven < 2.1) or native reactor command line options (Maven >= 2.1) to rebuild only a subpart of your project : -  All modules depending on module XXX -  All modules used to build XXX

●  Try to not use Maven features not supported by your IDE (resources filtering with the plugin eclipse:eclipse)


TO GO FURTHER … Apache Maven


DOCUMENTATIONS Apache Maven


Some links ●  The main web site :

-  http://maven.apache.org ●  Project’s team wiki :

-  http://docs.codehaus.org/display/MAVEN ●  Project’s users wiki :

-  http://docs.codehaus.org/display/MAVENUSER


Books ●  Sonatype / O’Reilly :

-  The Definitive Guide -  http://www.sonatype.com/

books -  Free download -  Available in several

languages ●  Soon in French


Books ●  Exist Global

-  Better builds with Maven -  http://www.maestrodev.com/

better-build-maven -  Free download


Books ●  Nicolas De loof

Arnaud Héritier -  Published by Pearson -  Collection Référence -  Based on our own

experiences with Maven. From beginners to experts.

-  In French only -  Available on 20th November


QUESTIONS ? Apache Maven


Licence et copyrights ●  Photos and logos belong to their respective

authors/owners ●  Content under Creative Commons 3.0

-  Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

-  Noncommercial — You may not use this work for commercial purposes.

-  Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

●  http://creativecommons.org/licenses/by-nc-sa/3.0/us/

Technology

Maven for eXo VN