Maven is a software tool for project management and builds automation. While primarily used for Java programming, it can also be used to build and manage projects written in C#, Ruby, Scala, and other languages.
Maven is the standard way to build projects and it also provides various other characters like clearing the definition of the project, ways to share jars across projects. It also provides the easy way to publish project information (OOS).
Maven serves a similar purpose to the Apache Ant tool, but it is based on different concepts and works in a profoundly different manner. Maven is hosted by the Apache Software Foundation, where it was formerly part of the Jakarta Project.
The primary goal of maven is to allow the developers to comprehend the complete state of a project in the shortest time by using easy build process, uniform building system, quality project management information (such as change Log, cross-reference, mailing lists, dependencies, unit test reports, test coverage reports and many more), guidelines for best practices and transparent migration to new features.
To achieve to this goal Maven attempts to deal with several areas like:
It makes the build process easy
Provides a uniform building system
Provides quality related project information
Provides guidelines related to development to meet the best goal.
Portable: Maven is portable in nature because it includes:
Building configuration using maven are portable to another machine, developer and architecture without any effort
Non trivial: Maven is non trivial because all file references need to be relative, environment must be completely controlled and independent from any specific file system.
Technology: Maven is a simple core concept that is activated through IoC container (Plexus). Everything is done in maven through plugins and every plugin works in isolation (ClassLoader). Plugings are downloaded from a plugin-repository on demand.
Faceoff ~ Maven vs Ant
When & Why Ant?
When & Why Maven
“Situational Software” which has to be developed quickly (in a few weeks / months).
You are working with many “creative” developers. It will be hard to establish a defined project structure etc. without tool support
Projects with external dependencies which are working with “cutting edge” libraries. There is no need for finer grained dependency management.
The developers are religious about their IDE and are using IntelliJ, NetBeans and Eclipse at the same time.
NetBeans projects :-). They come with predefined Ant scripts which even work perfectly with Hudson. Just check everything into svn and let hudson check it out.
You are building a product-like application. You will have to manage different versions and branches with their dependencies.
Legacy projects which do not fit the Maven conventions very well. Violating Maven conventions may become a hassle.
You project consists of several teams which work on dependent modules. These modules have to be composed to the application regularly.
Projects without explicit requirements for modularization. The deployable output will consist of only a few archives.
You plan to use checkstyle, pmd, generate a project website etc. It’s easy with Maven.
Ant gives the ultimate power and flexibility in build and deployment to the developer.
Maven adds a layer of abstraction above Ant (and uses Jelly). Maven can be used to build any Java application.
Dozens of lines in an Ant build script.
Today JEE build and deployment has become much standardized. Every enterprise has some variations, but in general it is all the same: deploying EARs, WARs, and EJB-JARs. Maven captures this intelligence and lets you achieve the build and deployment in about 5-6 lines of Maven script
Ant lets you do any variations you want, but requires a lot of scripting.
Maven on the other hand mandates certain directories and file names, but it provides plugins to make life easier.
Maven is essentially a project management and comprehension tool and as such provides a way to help with managing:
Maven uses a construct known as a Project Object Model (POM) to describe the software project being built, its dependencies on other external modules and components, and the build order. It comes with pre-defined targets for performing certain well-defined tasks such as compilation of code and its packaging.
Maven dynamically downloads Java libraries and Maven plug-ins from one or more repositories. Maven provides built-in support for retrieving files from the Maven Central Repository and other Maven repositories, and can upload artifacts to specific repositories after a successful build. A local cache of downloaded artifacts acts as the primary means of synchronizing the output of projects on a local system. Maven Tools Maven Phases
Project lifecycles are central to Maven. Most developers are familiar with the notion of build phases such as compile, test, and deploy. Ant has targets with names like those. In Maven 1, corresponding plug-ins are called directly. To compile Java source code, for instance, the java plug-in is used:
In Maven, this notion is standardized into a set of well-known and well-defined lifecycle phases. Instead of invoking plug-ins, the Maven developer invokes a lifecycle phase: $mvn compile.
Although hardly a comprehensive list, these are the most common default lifecycle phases executed.
validate: validate the project is correct and all necessary information is available
compile: compile the source code of the project
test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package: take the compiled code and package it in its distributable format, such as a JAR.
integration-test: process and deploy the package if necessary into an environment where integration tests can be run
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.
There are two other Maven lifecycles of note beyond the default list above. They are
* clean: cleans up artifacts created by prior builds
* site: generates site documentation for this project
Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the packaging type of the project. For example, package executes jar:jar if the project type is a JAR, and war:war is the project type is – you guessed it – a WAR.
An interesting thing to note is that phases and goals may be executed in sequence.
mvn clean dependency:copy-dependencies package
This command will clean the project, copy dependencies, and package the project (executing all phases up to package, of course).
Generating the Site
This phase generates a site based upon information on the project’s pom. You can look at the documentation generated under target/site. The POM
The pom.xml file is the core of a project’s configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively. This project’s POM is:
What Maven can Do?
A typical Maven site can publish, on a daily basis:
General project information such as source repositories, defect tracking, team members, etc.
Unit test and test coverage reports
Automatic code reviews and with Checkstyle and PMD
Configuration and versioning information
Source code in indexed and cross-referenced HTML format
Team member list
And much more
Maven – The Show Stopper
Maven simplifies build enormously by imposing certain fixed file names and acceptable restrictions like one artifact per project. Artifacts are treated as files on your computer by the build script. Maven hides the fact that everything is a file and forces you to think and script to create a deployable artifact such as an EAR. Artifact has a dependency on a particular version of a third party library residing in a shared remote (or local) enterprise repository, and then publishes your library into the repository as well for others to use. Hence there are no more classpath issues. No more mismatch in libraries. It also gives the power to embed even the Ant scripts within Maven scripts if absolutely essential.
Maven is a powerful tool that greatly simplifies and standardizes the build process. By promoting a standard project organization and recommended best practices, Maven handles much of the grunt work. And standard plug-ins such as the site generator provide valuable team-oriented project tools with little extra effort. Check it out!