Alpes Jug (29th March, 2010) - Apache Maven

Apache Maven - AlpesJUG - March 29th, 2010

Arnaud Héritier
eXo Platform
Software Factory Manager

Arnaud Héritier
●  Software Factory Manager
eXo platform
-  In charge of tools and
methods

●  Committer since 2004 and
member of the Project
Management Committee
●  Coauthor of « Apache
Maven » published by
Pearson (in French)
Licensed under a Creative Commons license

Apache Maven
CHOOSE YOUR MENU


Overview
●  Definition ●  Maven or not Maven, that
●  History is the question !
-  Maven, the project choice
●  Concepts
-  Maven, the corporate choice
-  Conventions
-  Competitors
-  POM
-  Reactor and Modules
-  Inheritance
-  Artifact Repository
-  Dependency
-  Version
-  Profiles
  Build Lifecycle And Plugins

Ecosystem
●  Repository Managers ●  Continuous Integration
●  Quality Management ●  IDE
-  Tests Automation -  Eclipse
-  Quality Metrics Reports -  Idea IntelliJ
-  Project Reports -  Netbeans
-  Sonar


Good & Bad Practices
●  K.I.S.S.
●  Project Organization
●  POM
●  Development


Usecases
●  Secure your credentials
●  Build a part of your project using reactor options
●  Automate your release process
-  (at least the technical part)


Back to the future
●  Maven 2.x
●  Maven 3.x
●  Community


Apache Maven
OVERVIEW


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.


History
●  Initiated in 2001 by Jason Van Zyl in Alexandria, an
Apache Jakarta project,
●  Moved to Turbine few months after,
●  Became a Top Level Project in 2003.
●  Maven 2.0 released in September 2005
●  Maven 3.0 … coming soon !!!


Apache Maven
CONCEPTS

Licensed under a Creative Commons license 12

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

●  Standardized
-  directories layout
●  *.java to compile in
src/[main|test]/java
●  *.xml, *.properties needed
in classpath and to bundle
in archive in src/[main|test]/java
●  …
-  project descriptor (POM)
-  build lifecycle

Licensed under a Creative Commons license 13

POM
●  An XML file (pom.xml) <?xml version="1.0" encoding="UTF-8"?>!
<project>!
<modelVersion>4.0.0</modelVersion>!

●  Describing <groupId>net.aheritier.samples</groupId>!
<artifactId>simple-webapp</artifactId>!

-  Project identification <version>1.1-SNAPSHOT</version>!
<packaging>war</packaging>!
-  Project version <name>Simple webapp</name>!

-  Project description <inceptionYear>2007</inceptionYear>!
<dependencies>!
-  Build settings <dependency>!
<groupId>org.springframework</groupId>!
-  Dependencies <artifactId>spring-struts</artifactId>!
-  … <version>2.0.2</version>!
</dependency>!
...!
</dependencies>!
</project>!


Reactor
●  Split your project in <project>!

sub-modules ...!
<modules>!

●  Maven computes the <module>moduleA</module>!

build order from <module>moduleB</module>!

dependencies <module>moduleC</module>!
between sub- <module>moduleD</module>!
modules. <module>moduleE</module> !

●  Modules have to be <module>moduleF</module>!

defined in the POM </modules>!
...!
-  No auto-discovery for </project>!
performance reasons


Inheritance
●  Share settings between
projects/modules
●  By default the parent
project is supposed to be
in the parent directory (../)

<parent>!
<groupId>net.aheritier.sample</groupId>!
<artifactId>my-parent</artifactId>!
<version>1.0.0-SNAPSHOT<version>!
</parent>!


Inheritance
Use a technical inheritance to organize sub-modules

Use assembly to package batchs

Insert README in all artifacts

Use clirr to validate backward compatibility


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
●  Used to store :
-  Project’s binaries
-  Project’s dependencies
-  Maven and plug-ins binaries


Dependencies
Without Maven With Maven


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 !
●  If you have optional dependencies
-  Perhaps you should have optional modules instead
●  Cleanup your dependencies with
-  mvn dependency:analyze!
●  Study your dependencies with
-  mvn dependency:tree!
-  mvn dependency:list!


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

●  Range
-  From … to …
-  Maven automatically searches for the corresponding
version (using the update policy for released artifacts)
-  To use with caution
●  Risk of non reproducibility of the build
●  Risk of side effects on projects depending on yours.


Versions
●  Use the versions plugin to update all versions of your
project and its modules
mvn versions:set –DnewVersion=A.B.C-SNAPSHOT!


Profiles
●  Allow to modify the default behavior of Maven by
overriding/adding some settings
●  Use mvn help:active-profiles to debug
●  Explicit activation or deactivation

mvn <phases or goals> !
-PprofileId1,-profileId2 !
-P!profileId3!


Profiles
●  activeByDefault = If no other profile is activated
●  Activation through Maven settings
<settings>!
...!
<activeProfiles>!
<activeProfile>profile-1</activeProfile>!
</activeProfiles>!
...!
</settings>!


Profiles
●  Activation based on environment variables

<profiles>!
<profiles>!
<profile>!
<profile>!
<activation>!
<activation>!
<property>!
<property>!
<name>run-its</name>!
<name>!skip-enforce</name>!
<value>true</value>!
</property>!
</property>!
</activation>!
</activation>!
...!
...!
</profile>!
</profile>!
</profiles>!
</profiles>!

Profiles
●  OS / Java settings
<profiles>!
<profile>!

<profiles>! <activation>!
<os>!
<profile>!
<name>Windows XP</name>!
<activation>!
<family>Windows</family>!
<jdk>[1.3,1.6)</jdk>!
<arch>x86</arch>!
</activation>!
<version>5.1.2600</version>!
...!
</os>!
</profile>!
</activation>!
</profiles>! ...!
</profile>!
</profiles>!

Profiles
●  Activation on present or missing files
<profiles>!
<profile>!
<activation>!
<file>!
<missing>${project.build.directory}/generated-sources/
axistools/wsdl2java/</missing>!
</file>!
</activation>!
...!
</profile>!
</profiles>!


Build Lifecycle And Plugins

●  Plugin based architecture
for a great extensibility
●  Standardized lifecycle to
build all types of
archetypes


Default Lifecycle Clean Lifecycle Site Lifecycle
validate pre-clean pre-site

initialize
clean site
generate-sources post-clean post-site

process-sources
site-deploy
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 Licensed under a Creative Commons license

●  Many plugins
-  Packaging
-  Reporting
-  IDE integration
-  Miscellaneous tools integration
●  Many locations
-  maven.apache.org
-  mojo.codehaus.org
-  code.google.com
-  …


Apache Maven
MAVEN OR NOT MAVEN,
THAT IS THE QUESTION !


Maven, the project’s choice
●  Application’s architecture
-  The project has the freedom to divide the application in
modules
-  Maven doesn’t limit the evolution of the application
architecture
●  Dependencies management
-  Declarative : Maven automatically downloads them and
builds the classpath
-  Transitive : We define only what the module needs
itself


Maven, the project’s choice
●  Centralizes and automates -  Builds
all development facets -  Tests
(build, tests, releases) -  Packages
●  One thing it cannot do for -  Deploys
you : to develop  -  Documents
-  Checks and reports about
the quality of developments


Maven, the corporate’s choice
●  Widely adopted and known
-  Many developers
●  Developments are standardized
●  Decrease of costs
-  Reuse of knowledge
-  Reuse of configuration fragments
-  Reuse of process and code fragments
●  Product quality improvement
-  Reports and monitoring


Competitors
●  Ant + Ivy, Easy Ant, Gant, Gradle, Buildr…
●  Script oriented
-  You can do what you want !
●  Reuse many of Maven conventions (directories
layout, …) and services (repositories) but without
enforcing them
●  The risk for them : Not being able to evolve due
to the too high level of customization proposed
to the user.
-  We tried on Maven 1 and it died because of that. It was
impossible to create a set of tests to cover all usages.
-  It’s like providing a framework without public API 

With scripts oriented builds
You can have But often you have


With Maven
We dream to deliver But today we have too often
Maven 3.x ? Maven 2.x


Apache Maven
ECOSYSTEM


Maven’s ecosytem
●  Maven alone is nothing
●  You can integrate it with many tools
-  A large set of plug-ins is already available
-  You can define your own plug-ins


Apache Maven
REPOSITORY MANAGERS


Repository Managers
●  Several products ●  Basic services
-  Sonatype Nexus (replaced -  Search artifacts
Proximity) -  Browse repositories
-  Jfrog Artifactory -  Proxy external repositories
-  Apache Archiva -  Host internal repositories
-  Security


Secure your builds
●  Deploy a repository manager to proxy externals
repositories to :
-  Avoid external network outages
-  Avoid external repository unavailabilities
-  To reduce your company’s external network usage
-  To increase the speed of artifact downloads
●  Additional services offered by such servers :
-  Artifacts procurement to filter what is coming from the
outside
-  Staging repository to validate your release before
deploying it


Nexus for productivity


Nexus for collaboration
●  Deploy 3rd Party Artifacts
●  Collaborate with Internal
Repositories
●  Distribute to the community
with Public Repositories
●  Distribute to customers
with Private Repositories


Nexus for quality
●  Ease the Burden on Central and others remote
repositories
●  Gain Predictability and Scalability
●  Control and Audit Dependencies and Releases
●  Stage releases


Apache Maven
QUALITY MANAGEMENT


Tests Automation
●  Use automated tests as often as you can
●  Many tools are available through Maven
-  JUnit, TestNG – unit tests,
-  Selenium, Canoo – web GUI test,
-  Fitnesse, Greenpepper – functional tests,
-  SoapUI – web services tests
-  JMeter – performances tests
-  And many more frameworks are available to reply your
needs


Quality Metrics
●  Extract quality metrics from your project and
monitor them :
-  Code style (CheckStyle)
-  Bad practices or potential bugs (PMD, FindBugs, Clirr)
-  Tests coverage (Cobertura, Emma, Clover)
-  …
●  You can use blocking rules
-  For example, I break the build if the upward
compatibility of public APIs is broken
●  You can use reports
-  Reports are available in a web site generated by
Maven
-  Or in a quality dashboard like Sonar

Dependency Report


Sonar, a quality dashboard


Sonar, analyze your project


Sonar, Continuous Improvement ?


Apache Maven
CONTINUOUS INTEGRATION


Continuous Integration
●  Setup a continuous integration server to :
-  Have a neutral and unmodified environment to run your
tests
-  Quickly react when
●  The build fails (compilation failure for example)
●  A test fails
●  A quality metric is bad
-  Continuously improve the quality of your project and
your productivity
●  Many products
-  Hudson, Bamboo, TeamCity, Continuum,
Cruisecontrol, …

Hudson, how the weather is ?


Hudson : build, test, check


Apache Maven
IDE


Eclipse


Idea IntelliJ


Netbeans


Apache Maven
GOOD & BAD PRACTICES


Apache Maven
KISS


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
●  …


Apache Maven
PROJECT ORGANIZATION


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 …


Apache Maven
POM GOOD & BAD PRACTICES


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.


Apache Maven
DEVELOPMENT


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)

Apache Maven
USECASES


Apache Maven
SECURE YOUR CREDENTIALS


Secure your credentials
●  Generate a private key
-   
arnaud@leopard:~$ mvn --encrypt-master-password toto 
{dZPuZ74YTJ0HnWHGm4zgfDlruYQNda1xib9vAVf2vvY=} 

●  We save the private key in ~/.m2/settings-security.xml

<settingssecurity>!
<master>{dZPuZ74YTJ0HnWHGm4zgfDlruYQNda1xib9vAVf2vvY=}</master>!
</settingssecurity>!


Secure your credentials
●  You can move this key to another drive ~/.m2/settings.xml
-  <settingssecurity> 
<relocation>/Volumes/ArnaudUsbKey/secure/settings-security.xml</relocation> 
</settingssecurity>!

●  You create an encrypted version of your server
password
-  arnaud@mbp-arnaud:~$ mvn --encrypt-password titi
{SbC9Fl2jA4oHZtz5Fcefp2q1tMXEtBkz9QiKljPiHss=}!

●  You register it in your settings
-  <settings> 
... 
<servers> 
... 
<server> 
<id>mon.server</id> 
<username>arnaud</username> 
<password>{SbC9Fl2jA4oHZtz5Fcefp2q1tMXEtBkz9QiKljPiHss=}</password> 
</server> 
... 
</servers> 
... 
</settings>!


Apache Maven
BUILD A PART OF YOUR PROJECT


Reactor options (Maven > 2.1)
-  arnaud@mbp-arnaud:~$ mvn install 
[INFO] ------------------------------------------------ 
[INFO] Reactor Summary: 
[INFO] 
[INFO] Project ....................... SUCCESS [2.132s] 
[INFO] ModuleA ....................... SUCCESS [5.574s] 
[INFO] ModuleB ....................... SUCCESS [0.455s] 
[INFO] ModuleC ....................... SUCCESS [0.396s] 
[INFO] ModuleD ....................... SUCCESS [0.462s] 
[INFO] ModuleE ....................... SUCCESS [0.723s] 
[INFO] ModuleF ....................... SUCCESS [0.404s]
!

●  Builds everything from A to F


-  arnaud@mbp-arnaud:~$ mvn install –pl
moduleE,moduleB 
[INFO] ------------------------------------------- 
[INFO] 
[INFO] ModuleB .................. SUCCESS [2.774s] 
[INFO] ModuleE .................. SUCCESS [1.008s] 

●  Builds only modules B and E
●  Following dependencies order
●  -pl --project-list: Build the
specified reactor projects instead
of all projects


-  arnaud@mbp-arnaud:~$ mvn install –pl moduleD -am 
[INFO] ------------------------------------------ 
[INFO] 
[INFO] ModuleA ................. SUCCESS [4.075s] 
[INFO] ModuleB ................. SUCCESS [0.468s] 
[INFO] ModuleC ................. SUCCESS [0.354s] 
[INFO] ModuleD ................. SUCCESS [0.384s] 

●  Builds module D (-pl) and all
modules it uses as dependencies
●  -am --also-make: If a project list
is specified, also make projects
that the list depends on
●  Usecase : Build all modules
required for a war, ear, …

-  arnaud@mbp-arnaud:~$ mvn install –pl moduleD -amd 
[INFO] ------------------------------------------ 
[INFO] 
[INFO] ModuleD ................. SUCCESS [4.881s] 
[INFO] ModuleE ................. SUCCESS [0.478s] 
[INFO] ModuleF ................. SUCCESS [0.427s] 

●  Builds module D (-pl) and all
modules which depend on it
●  -amd --also-make-dependents: If
a project list is specified, also
make projects that depend on
projects on the list
●  Usecase : Check that a change in
a module didn’t break others
which are using it

Apache Maven
RELEASE YOUR PROJECT


Release of a webapp in 2002
●  Limited usage of eclipse
-  No WTP (Only some features in WSAD),
-  No ability to produce WARs


●  Many manual tasks
-  Modify settings files
-  Package JARs
-  Copy libraries (external and internal) in a « lib »
directory
-  Package WAR (often with a zip command)
-  Tag the code (CVS)
-  Send the package on the integration server using FTP
-  Deploy the package with AS console


●  One problem : The are ●  How long did it take ?
always problems -  When everything is ok : 15
-  Error in config files minutes
-  Missing dependencies -  When there’s a problem : ½
-  Missing file day or more
-  Last minute fix which created a bug
-  And many other possibilies ..


Maven Release Plugin
●  Automates the release process from tagging
sources to binaries delivery
●  Release plugin main goals:
-  Prepare : To update maven versions and information in
POMs and tag the code
-  Perform : To deploy binaries in a maven repository
●  After that you can just automate the deployment on
the AS using cargo for example.


Maven Release Plugin


Configuration and Prerequisites
●  Project version (must be a SNAPSHOT version)
●  Dependencies and plugins versions mustn’t be
SNAPSHOTs


SCM configuration
●  SCM binaries have to be in the PATH
●  SCM credentials have to already be stored or you have to
pass them in command line with :
–Dusername=XXX –Dpassword=XXX
<scm>
<connection>
scm:svn:http://svn.exoplatform.org/projects/parent/trunk
</connection>
<developerConnection>
scm:svn:http://svn.exoplatform.org/projects/parent/trunk
</developerConnection>
<url>
http://fisheye.exoplatform.org/browse/projects/parent/trunk
</url>
</scm>

Distribution Management
<project>
<distributionManagement>
<repository>
<id>repository.exoplatform.org</id>
<url>${exo.releases.repo.url}</url>
</repository>
. . .
</distributionManagement>
. . .
<properties>
<exo.releases.repo.url>
http://repository.exoplatform.org/content/repositories/exo-releases
</exo.releases.repo.url>
. . .
</properties>
</project>


Repository credentials
<settings>
<servers>
<server>
<!–- id must be the one used in distributionManagement -->
<id>repository.exoplatform.org</id>
<username>aheritier</username>
<password>{ABCDEFGHIJKLMNOPQRSTUVWYZ}</password>
</server>
</servers>
</settings>


Default Release Profile in Super POM
<profile>
<id>release-profile</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<!–- Configuration to generate sources and javadoc jars -->
...
</plugins>
</build>
</profile>


Custom release profile
<project> ...

... <profiles>

<build> <profile>

<pluginManagement> <id>myreleaseprofile</id>

<plugins> <build>

<plugin> <!-– what you want to customize the behavior of
the build when you do a release -->
<groupId>org.apache.maven.plugins</groupId>
</build>
<artifactId>maven-release-plugin</artifactId>
</profile>
<version>2.0-beta-9</version>
</profiles>
<configuration>
...
<useReleaseProfile>false</useReleaseProfile>
</project>
<arguments>-Pmyreleaseprofile</arguments>

</configuration>

</plugin>

</plugins>

</pluginManagement>

</build>


Troubleshooting Releases
●  Common errors during release:
-  Build with release profile was tested before and fails
-  Local modifications
-  Current version is not a SNAPSHOT
-  SNAPSHOTs in dependencies and/or plugins
-  Missing some configuration (scm, distribMgt, …)
-  Tag already exists
-  Unable to deploy project to the Repository
-  Connection problems


Apache Maven
BACK TO THE FUTURE


Apache Maven
PRODUCT


Apache Maven 2.0.x
●  bugs fix
●  Last release : 2.0.11
●  No other release of 2.0.x in the future


Apache Maven 2.x
●  Evolutions, new features
●  Several important new features in 2.1 like
-  Parallel downloads
-  Encrypted passwords

●  Last release : 2.2.1


Apache Maven 3.x
●  Do not be afraid !!!!!
●  Not final before at least
one year
●  Full compatibility with
maven 2.x projects


Apache Maven 3.x
●  What’s new :
-  How POMs are constructed
-  How the lifecycle is executed
-  How the plugin manager executes
-  How artifacts are resolved
-  How it can be embedded
-  How dependency injection is done


Apache Maven 3.x
●  What it will change for maven users ?
-  Any-source POM
-  Versionless parent elements
-  Mixins : a compositional form of Maven POM
configuration
-  Better IDE integration
-  Error & integrity reporting
●  Much improved error reporting where we will provide links to
each identifiable problem we know of. There are currently 42
common things that can go wrong.
●  Don't allow builds where versions come from non-project
sources like local settings and CLI parameters
●  Don't allow builds where versions come from profiles that
have to be activated manually


Apache Maven 3.x
●  What it will change for maven developers ?
-  Lifecycle extension points
-  Plugin extension points
-  Incremental build support
-  Queryable lifecycle
-  Extensible reporting


Apache Maven 3.x
●  New tools
-  Tycho : OSGI, Eclipse
-  Mvnsh


Maven Shell


Apache Maven
COMMUNITY


Users community
●  1780 subscribers on users
mailing list

●  90 days statistics
●  Number of subscribers in blue
●  Number of messages per day in red


The web site


Dowloads

●  Per month downloads


The team
●  60 committers,
●  More than 30 active in 2009,
●  Several organizations like Sonatype, deliver
resources and professional support,
●  A community less isolated : more interactions with
Eclipse, Jetty,


Commit Statistics


Apache Maven
CONCLUSION


Conclusion
●  Today, Maven is widely adopted in corporate
environments,
●  It provides many services,
●  It has an important and really active community of
users and developers
●  Many resources to learn to use it and a
professional support are available
●  A product probably far from being perfect but on
rails for the future
●  Many things to do
-  We need you !

Apache Maven
QUESTIONS ?


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/


Apache Maven
TO GO FURTHER …


Apache Maven
DOCUMENTATIONS


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


Apache Maven
SUPPORT


Support
●  Mailing lists
-  http://maven.apache.org/mail-lists.html
●  IRC
-  irc.codehaus.org - #maven
●  Forums
-  http://www.developpez.net/ forum maven
-  In French
●  Dedicated support
-  Sonatype and some others companies


Apache Maven
ANNEXE


Setup a global mirror
<settings>
<mirrors>
<mirror>

<id>global-mirror</id>
<mirrorOf>external:*</mirrorOf>
<url>http://repository.exoplatform.org/content/groups/all</url>
</mirror>
</mirrors>
<profiles>
<profile>
<id>mirror</id>


<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>

<activeProfile>mirror</activeProfile>
</activeProfiles>
</settings>

Alpes Jug (29th March, 2010) - Apache Maven

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Alpes Jug (29th March, 2010) - Apache Maven

Similar to Alpes Jug (29th March, 2010) - Apache Maven (20)

More from Arnaud Héritier

More from Arnaud Héritier (20)

Recently uploaded

Recently uploaded (20)

Alpes Jug (29th March, 2010) - Apache Maven