Introduction to project industrialization with Maven 2

Event

http://www.yajug.lu

October 06 2009 Best Practices and Tools for your build environments

Speaker

Pierre-Antoine Grégoire

I.T.Architect at

Occasional committer in open source projects

Dislikes buzzwords (SOA, EDA…), likes to conceptualize and build architectures

Thinks having fun and working seriously (both at the same time) should be mandatory!

Who are you?

Who in the audience is currently coding at work?

Who in the audience is managing the lucky coders?

Who is already using Maven 2+?

Who is planning on using it and came to have more information?

Planning

Software development is engineering

A bit of history

Why Maven?

An introduction to Maven

Drawbacks of Maven

Best practices

Maven 3.x preview

Maven in a Software development suite

Since the early days of modern engineering, automation of build processes has been the key to:

Productivity improvements

Quality insurance

Failure-Proofing

Why would software development be any different?

How do you really enable automation of build?

Build has to be reproducible

Build has to produce the final production artifact

Build has to be as easy to maintain as possible and well documented

Build has to contribute to the standardization effort

Planning

A bit of history

Why Maven?

Drawbacks of Maven

Best practices

Maven 3.x preview

A bit of history

Software craftmens are lazy, so they are looking for efficiency (or the other way around… )

One command line to launch for a build, OK

Two command lines to launch for a build, BAD enough

More… forget it…

Disclaimer: I’m one of these lazy craftmen…

A bit of history

A simple script (.sh, .bat) is already a possible solution

More advanced command-line tools have been available for a long time

make created in 1977 at Bells Labs by Stuart Feldman

Still very much used nowadays

Apache Ant created by James Duncan Davidson

Was at first a platform-independent build system for Tomcat because Sun’s build system for Servlet RI (From which Tomcat was derived) was specific to Solaris.

Released separately in 2000

A bit of history

Two main categories in current tools

Scripting tools

Ant and derived (XML)

Rake (Ruby based)

Gradle (Groovy based)

… many others

Artifact oriented tools

Maven

Debian Package Creation

A bit of history

Maven 1.x is now a 10 years old project, mostly motionless since 2007 (no insult intended to people still using it or committing to it)

Maven 2.x is the de facto standard for Java and Java EE build

Most open source projects are switching to Maven for their build system

It’s now five years old

Planning

A bit of history

Why Maven?

Drawbacks of Maven

Best practices

Maven 3.x preview

Why Maven?

Nowadays, build tools are not really used by developers directly.

IDEs are increasing their functionalities scope,

Compilation is almost always done on the fly

Package and server startup is monitored by rich Uis

Step-by-step debugging is a killer feature

Build tools like Maven 2 are used to build the package you will put into production! This should never be done by an IDE, nor by hand!

Why Maven?

If you are not already using it:

Now is the best moment to start being aware

Maven is mature

Maven is getting better and better

Maven can be used online, offline, and in enterprise environment

If you are already using it:

Hang on! The best is yet to come!

Focus on necessary things and don’t get frustrated by petty details

Planning

A bit of history

Why Maven?

Drawbacks of Maven

Best practices

Maven 3.x preview

Maven 2 is a tool with multiple facets:

a BUILD tool

a DEPENDENCY MANAGEMENT tool

a DOCUMENTATION tool

An introduction to Maven Copyright © Pierre-Antoine Grégoire License Creative Commons 2.0 Project Object Model pom.xml mvn Generated artifacts (jar, war, ear…) , Documentation, statistics (test results, quality metrics, javadoc, web site) …

A project can easily be cut into modules thanks to Maven 2

By simply declaring project metadata and optionally configuring a few plug-ins, you can:

Build your project (compile, generate sources …)

Launch tests and gather results (Junit, TestNG, Selenium…etc)

Package (Jar, War, Ejb, War…etc)

Document and generate reports

Project Object Model (POM)

Basic project information

groupId, artifactId, version…

Inheritance, or Aggregation through sub-modules (we’ll explain the difference later on)

Build section

Project layout (sources and resources folders… etc)

Build plugins configuration

Reporting section

Reports configuration

Some other advanced environment settings

A plug-in is made of a MOJO (Maven POJO) which is simply a java class with Maven-specific metadata.

A plug-in can define goals and reports

Goals can be called directly:

mvn plugin:goal

Goals can be bound to one or multiple phases

Reports are used during site generation

mvn site

When you invoke a phase, Maven 2 will go through all the phases until the one specified, executing the bound goals:

mvn package

There are many more phases than in previous examples in the default lifecycle

By default, all the basic necessary plug-ins for the build phase are already bound to phases

It is easy to have information about plugins:

mvn help:describe

So….. what’s left to do, and what’s all the fuss about the complexity of Maven 2?

Dependencies: A blessing and a curse

Blessing:

almost all java build tools nowadays leverage the Maven 2 repositories (cf. Ivy, Ant, Gradle…etc)

easier to find/discover/use java libraries

Curse:

Transitive dependencies can rapidly trigger a dependency hell!

Curse: Harder to stabilize builds

What really made Maven different from other builds systems in the first place?

REPOSITORIES !!!

Before Maven, it was really hard to find java libraries, and harder to ensure a coherent use of these libraries (I’m saying hard, not impossible…)

Nowadays, it’s still very hard to find some jars with a decent/coherent versioning (discretely winking in the general direction of Sun participants...), let alone to find their sources or javadocs

Local repository:

Local cache for artifacts

Local private sandbox

It should be possible to erase it regularly

Very useful for offline builds

By default in user home’s .m2/ folder

Can be moved to another place through Maven 2 runtime’ settings.xml file

$MAVEN_HOME/conf/settings.xml

Corporate repository/proxy

Very useful tool

The first necessary step towards a corporate use of maven

Can be as simple as a corporate http server exposing a repository

Even better: install a repository management tool

Can proxy external repositories

Can filter unwanted artifacts

Build even without internet access! (well… at least for the repository management tool)

Public repositories

Good for dependencies’ harvesting

Should be proxied in corporate environments… or even for your personal use!

A lot of mis-configured dependencies

A lot of alpha/beta Maven 2 plug-ins

Be cautious when adding public repositories to a build process!

Other key features of Maven:

POM Inheritance/Aggregation

Archetypes

Launching Tests

… many more…

POM Inheritance vs. POM Aggregation

POM Inheritance :

a POM and all its parent POMs will be flattened at runtime

In the end only one effective POM in memory

This is mostly used to share common configuration

POM Aggregation :

declare modules in a given project

If a command is issued against a project, it will be also issued against all its modules

This is mostly used to organize builds and gather projects that should be built simultaneously

Project Archetypes

You can build template projects and make them available as artifacts in the repositories

Allows to share best practices without neither inheritance nor aggregation

mvn archetype:create-from-project

mvn archetype:generate

Many Archetypes already configured in the default catalog

You can easily build a custom or corporate catalog

mvn archetype:generate

– DarchetypeCatalog=http://www.corporate.com/archetypes.xml

Launching Tests

Maven 2 allows to launch various types of tests:

Unit tests: Junit 3.x or 4.x, TestNG, …

UI Tests: Selenium, Canoo Webtest

Functional tests: Fitnesse, Greenpepper

WebServices tests: SOAPUi

And many more…

Planning

A bit of history

Why Maven?

Drawbacks of Maven

Best practices

Maven 3.x preview

Drawbacks of Maven

If you don’t embrace the standardization brought by Maven 2, you’ll soon feel limited by Maven 2

Additionally, standardization can be quite expensive! Measure the implied cost by testing on 2 subsequent projects (one to absorb the POC effect, and one for measure)

By default Maven 2 has its own folder structure normalization, unknown to IDEs (though this is not completely true anymore)

Last but not least: Maven 2 error reporting is SO BAAAAD!

Worst practices

You want more drawbacks? GET MORE OF THEM!

Use maven-antrun-plugin a lot!

So coool, this way you can use Maven and not Ant!

Build very intricated projects with modules having modules themselves, and lots of inheritances all around!

Niiice! This allows you to spend more time with your favorite tool: Maven 2 in order to find out where your damn properties/dependencies are defined!

Replace your IDE with Maven and try to add all of your IDE’s functionalities as Maven plugins!!!!!

You got my point ;)

Planning

A bit of history

Why Maven?

Drawbacks of Maven

Best practices

Maven 3.x preview

Best practices

They will allow you to overcome Maven 2’s drawbacks

Embrace the standardization brought by Maven 2, don’t fight it

Use POM Inheritance and <dependencyManagement> (with import scope) , <pluginManagement> to tame the transitive dependencies. (don’t mistake these for <dependencies> , <plugins>… )

Use a Repository Manager:

Sonatype Nexus: http://nexus.sonatype.org

Jfrog Artifactory: http://artifactory.jfrog.org

…

Best practices

Don’t use Maven’s integrated reporting anymore

It was meant for Apache project’s web sites static documentation

The amount of time spent in order to build them is not worth it in enterprise environment

Keep your build as simple as possible

Generate test statistics data and other metrics data in order to exploit them in Software quality tools:

Sonar: http://sonar.codehaus.org

Squale: http://www.squale.org

…

Best practices

If you provide a standard environment, try to make Maven plugins have a match in the IDE

If Maven 2 launches Checkstyle, provide the Checkstyle Eclipse plugin to your projects.

Launch your builds regularly and possibly in a neutral zone (not on the developer’s desktop!) in order to ensure “rule number one” is respected: Build must be reproducible.

Use the “dependency” and “versions” plugins to handle dependencies and diagnose dependencies mismatches or errors

Best practices

Documentation and information:

Site http://maven.apache.org

Plugins

http://maven.apache.org/plugins

http://mojo.codehaus.org/

http://code.google.com/

And many others…

Project Wiki http://docs.codehaus.org/display/MAVEN/

Users’ Wiki http://docs.codehaus.org/display/MAVENUSER

Best practices

Books

Free electronic editions:

Definitive Guide: http://www.sonatype.com/books

Better Builds with Maven: http://www.maestrodev.com/better-build-maven

Upcoming book by Arnaud Héritier and Nicolas De Loof

http://www.pearson.fr/livre/?GCOI=27440100730370

Planning

A bit of history

Why Maven?

Drawbacks of Maven

Best practices

Maven 3.x preview

Maven 3.x Preview

DISCLAIMER!!!

Everything mentioned here could end up being COMPLETELY FALSE!!! (though project is now well advanced)

Maven 3.x Preview

New release planned for this autumn/winter

Lots of refactorings of the insides of Maven 2

Not immediately obvious (in a way this is better than the complete product change between Maven 1 and 2)

Will allow to tackle upcoming challenges and regular issues of Maven 2 in a more elegant manner

Simplifies plug-in development

Efficient embedder

Maven 2 has lots of singletons and such and is therefore improper for use in multithreaded environments (CIM, IDE)

Maven 3.x Preview

Backward compatibility

Loads of Integration testing is done to ensure backwards compatibility

Stricter validation of the POM

Configured plugins should have their versions specified (a warning appears otherwise)

Site/reporting is now completely extracted from the Maven core

Currently the Site plugin doesn’t work with Maven 3, yet should until the final release (though reports still work)

Recommended to switch to the use of external quality monitoring tools

Maven 3.x Preview

If you plan to migrate or want to evaluate: http://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes

Presentation by Jason van Zyl (Sonatype) http://www.scribd.com/doc/14458957/Jasons-Maven-3-Presentation

My first impressions:

Maven 3 looks awesome!

Embedder is a killer feature

The IDE can literally listen for the Build process, and be part of it, not just launch it.

Maven 3.x Preview

What will be new to users:

Versionless parent elements

Better version delegation

Better error and integrity reporting

XML Pom format using attributes instead of elements

Scripted POM Formats (pom.{rb|groovy|py})

What will be new to plugin developers:

Plugin extension points

Annotations instead of old javadoc tags

Lifecycle extension points

Queryable lifecycle

Maven is now very well integrated in IDEs

NetBeans 6.5+ now has very good support for Maven 2

Eclipse 3.x has very good support also, with preview of Maven 3.x embedder (blazingly fast!)

IntelliJ IDEA seems to have excellent support also (though this is why you pay for it isn’t it?)

Maven works very well with Quality monitoring tools

Maven 3 will most likely increase the embedding of Maven and its use for other JVM Languages and possibly for other platforms

References and Thanks

Many thanks to Arnaud Héritier

He allowed me to be inspired by some of its recent slides presented to the French Ch’ti JUG

http://blog.aheritier.net

He also was kind enough to review this presentation ;)

Many thanks to Jason van Zyl for its Maven 3 presentation I was heavily inspired by

http://www.sonatype.com/people/author/jason

Introduction to project industrialization with Maven 2

0 comments

Notes on slide 1

1 Favorite