This article covers basic concepts of maven self. Lastly i described how to setup maven.

Introduction

Maven is a project management framework (or tool).

This definition is relatively abstract and doesn’t justifies the richness and of Maven. Let me try to describe maven by looking at the central idea and it was the adoption of best practices/principles (of that time):

  • Convention over configuration
  • Declarative execution
  • Reuse of build logic
  • Coherent organization of dependencies

Let’ see how maven adopts these. Here are the key concepts maven provides:

  • Set of build standards
  • Standard life cycles for building, testing and so on
  • Default Tasks
  • Common declarative Project Object Model (POM)
  • Dependencies description and management
  • Artifact repository
  • Modular Design (Plug-ins)

Maven provides a comprehensive model that can be applied to all software projects. That model uses a common project “language”, and the software tool is just a supporting element within this model.

Maven is not like Ant

For a long time I was an Apache Ant user it’s important for me to emphasize some key differences in maven philosophy.

  • Pre-defined (non just project-wide) build standards, with pre-defined default life cycles, directory layout, and more. Can say maven has predefined assumptions on how to build your project (I don’t say that I like it in any sense)
  • It’s possible to build any given project without having to understand how the individual plug-ins work.
  • Maven provides a declarative style. Instead of defining procedures you configure them.

Maven Project Object Model (POM)

A File named pom.xml is XML representation of “Project Object Model” an always a central place of any maven project. We can think of it as maven project definition file. Or as maven POM states

It is a one-stop-shop for all things concerning the project. In fact, in the Maven world, a project need not contain any code at all, merely a pom.xml

Every project begins with basic POM

<project xmlns="http://maven.apache.org/POM/4.0.0" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0"
 http://maven.apache.org/xsd/maven-4.0.0.xsd> 
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>
</project>

These three elements define the ID of an artifact and in the effect of the particular build results.

groupId:artifactId:packaging:version

If the packaging is omitted “jar” is assumed. The Apache Maven POM Reference covers all the aspects of the POM. To cover all aspects of the POM would need a lot of time. It’s better take examples and adopt them, but sometimes it’s worth to look at POM Reference

The POM-Tree gives a quick overview, what it is all bout. Of course you don’t have to be familiar with all that parts of the tree. It is usual to start working with simple pom and extending it step by step if default behavior is not sufficient. Therefore pom.xml represents static project configuration, let’s look how this configuration apply on build-time.

Lifecycles

Lifecycle is essential concept of maven. There are tree pre-defined Lifecycles:

  • Clean, Build and Site.

Every lifecycle defines an ordered set of Phases. If Clean-Lifecycle and Site-Lifecycle defines 3 and 4 Phases respectively. T

The Build Life-Cycle

The main Lifecycle is the default Lifecycle sometimes called the “Build Life-Cycle” and has 23! phases:

  1. validate
  2. initialize
  3. generate-sources
  4. process-sources
  5. generate-resources
  6. process-resources
  7. compile
  8. process-classes
  9. generate-test-sources
  10. process-test-sources
  11. generate-test-resources
  12. process-test-resources
  13. test-compile
  14. process-test-classes
  15. test
  16. prepare-package
  17. package
  18. pre-integration-test
  19. integration-test
  20. post-integration-test
  21. verify
  22. install
  23. deploy

and for the sake of completeness:

Clean Life-Cycle

  1. pre-clean
  2. clean - remove all files generated by the previous build
  3. post-clean

Site Life-Cycle

  1. pre-site
  2. site - generate the project’s site documentation
  3. post-site
  4. site-deploy

These build phases are executed sequentially in the given order. To do all those, you only need to call the last build phase to be executed, in this case, deploy:

mvn deploy

and

mvn install

will execute all phases except deploying and do on. It is also possible to call phases of different life-cycles e.g. mvn clean install this command will traverse into all of the life-cycles and run clean including all of the prior steps then install in the same way.

Maven Goals

A Goal represents a specific task (finer than a build phase) which actually caries out the amount of work. So this is also you should know about goals:

  • A goal may be bound to zero or more build phases.
  • If a build phase has no goals bound to it, that build phase will not executed.
  • A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation

this is probably too bulky, let try it on example:

mvn clean dependency:copy-dependencies package

dependency:copy-dependencies is an unbound goal, which is executed as it is. clean and package are phases and executed like phases with predecessors. Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.

Some phases have goals bound to them by default. And for the default lifecycle, these bindings depend on the packaging value. Therefore it’s getting essential to know how some Built-in Lifecycle bindings. And then to know the default plugin set used by them. Effectively goals that are bound by default are executed every time in the default configuration.

The POM file in fact is the place where all the plugins goals and binding are defined alongside with the parameters you can set.

Profiles

Profiles modify the POM at build time and are meant to be used to provide context-dependent configuration. For example, they allow defining test and production context without creating several different POM definitions. Profile definitions are created inside of pom.xml or settings.xml following the same inheritance rules as the rest of POM file (read above).

Profiles can be used explicitly from the command line

mvn groupId:artifactId:goal -P profile-1, profile-2

or defined as default active inside settings.xml

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

But in case of pom definition it is considerable to use use “smart activation” of a profile. Example below show’s example profile definition which will be activated automatically on apple mac computers. The defined Profiled with id default_mac only set property: build.style="Macintosh"

<profile>
   <id>default_mac</id>
   <activation>
       <os>
        <family>mac</family>
      </os>
  </activation>
   <properties>
      <build.style>Macintosh</build.style>
  </properties>
</profile>

Visit Profiles explanation for more examples.

I hope this helps someone to go quick and dirty familiar with maven. For details pleas ask questions or see following resources.