Saturday, October 8, 2016

Introduction to maven

What is Maven ?

Maven is a project management tool, based on the concept of a project object model (POM).
Maven includes a project lifecycle, a dependency management system and execution of plugin goals at defined phases in a lifecycle.

Convention over configuration

Maven uses convention over configuration. Convention over configuration means that the system assume resonable defaults and the user is not required to do the configuration of the system.

Maven's conventions apply to build phases:

  • a maven project is assumed to produce a JAR file.
  • maven defines a default lifecycle and a set of common plugins that know how to build and integrate software.
  • maven core plugins apply conventions for many common processes.

Maven provides default location of directories:

  • the source code is assumed to be in basedir/src/main/java
  • the tests are assumed to be in basedir/src/test/java
  • the resources are assumed to be in basedir/src/main/resources
  • the compiled code is in basedir/target/classes
  • the JAR is in basedir/target

When you use maven, you write your source code and if you follow the conventions, you only have to put the code in the predefined directory, maven will take care of the rest.

A common interface

Maven provides a common interface for building software.

  • Before maven, each project had its approach to build software and developers moving to a new project had to take time away from writing software to learn how to build the project.
  • These days, you check the project and run mvn install.
Universal reuse of capabilities through Maven plugins

Maven retrieves dependencies and plugins from the remote repository.

Plugins are a way to add behavior when building projects:

  • for example, the maven Surefire plugin is responsible for running unit tests.
  • suppose that maven add support for TestNG testing framework in addition to JUnit
  • if you decide to use this new feature, you don't have to install new software, you only have to update the version number for a plugin in the POM: you will be able to write new unit tests and your old test will continue to execute without fail.
A conceptual model of a project
Maven keeps a model of a project in the POM file:
  • the model is a description of the software project
  • the model assigns a unique set of coordinates to a project
  • the model contains attributes of the project such as
    • a set of coordinates: (a group id, an artifact id, version)
    • the other projects this project depends upon.
The project model enables features such as:
  • dependency management made possible by the presence of project coordinates
  • remote repository of maven artifacts ordered by coordinates
  • reuse of build logic contained in plugins which work with the configurations defined in the POM file
  • searching and indexing maven artifacts stored in repository through the Nexus repository manager which work with information in the POM
  • project portability through different IDE/tools which now find project information in the POM file
Comparing Maven with Ant

Below, two files, an ant build.xml and a maven pom.xml, which achieve the same result.

Ant is a build tool with targets and dependencies:
  • each target is a set of tasks (goals) that are instructions coded in XML.
  • sample tasks are the: copy, javac and jar tasks
All you need to do in Maven is create a simple maven pom.xml file, place the source file in the default directory and run "mvn install".
sample build.xmlsample pom.xml
<project name="my-project" default="dist" basedir=".">
  <description>simple example build file</description>
  <!-- set global properties for this build -->
  <property name="src" location="src/main/java"/>
  <property name="build" location="target/classes"/>
  <property name="dist" location="target"/>
  <target name="init">
    <!-- Create the time stamp -->
    <!-- Create the build directory structure used by compile -->
    <mkdir dir="${build}"/>
  <target name="compile" depends="init" description="compile the source " >
    <!-- Compile the java code from ${src} into ${build} -->
    <javac srcdir="${src}" destdir="${build}"/>
  <target name="dist" depends="compile" description="generate the distribution" >
    <!-- Create the distribution directory -->
    <mkdir dir="${dist}/lib"/>
    <!-- Ouput into ${build} into a MyProject-${DSTAMP}.jar file -->
    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>

  <target name="clean" description="clean up" >
    <!-- Delete the ${build} and ${dist} directory trees -->
    <delete dir="${build}"/>
    <delete dir="${dist}"/>

Ant vs Maven
  • Ant does not have conventions, while Maven has conventions: Maven knows where the source code is and Maven compiler plugin knows where to put the bytecode.
  • Ant is procedural while Maven is declarative: you have to tell Ant exactly what to do, with Maven all you need to do is write a pom.xml file and put code in default directory.
  • Ant does not have a lifecycle while Maven has a lifecycle: with Ant you have to define tasks and task dependencies, instead, when you invoke "mvn install", Maven executes a series of lifecycle phases and as Maven moves through the sequential phases it executes default plugin goals which do things like compile and create a JAR.

Introduction to the Build Lifecycle

Maven is based on the concept of a build lifecycle. A lifecycle is a well defined process for building and distributing a project.

There are three built-in build lifecycles:

  • the default lifecycle handles the project build and distribution
  • the clean lifecycle handles project cleaning
  • the site lifecycle handles the creation of documentation of the project
A Build Lifecycle is Made Up of Phases

Each build lifecycles is defined as a list of build phases, where a build phase represents a step in the lifecycle. For example, the main phases of the default lifecycle are:

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.
package - package the compiled code in distributable format, such as a .jar file.
verify - run any checks on results of integration tests to ensure quality criteria are met
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - copy the final package to the remote repository for sharing with other developers and projects.

The lifecycle phases are executed sequentially to complete the default lifecycle.

A Build Phase is Made Up of Plugin Goals

The manner in which a build phase carries out its responsibilities may vary and depends on the plugin goals bound to that build phase. Each phase has zero or more plugin goals bound to it.

  • A goal represents a specific task which contributes to the building and managing of a project.
    • examples of goals include the compile goal in the Compiler plugin or the test goal of the Surefire plugin
  • A plugin is a collection of one or more goals; a plugin is a maven artifact which contains one or more Maven Old Java Objects, or mojos. Where each mojo implements a goal in Maven.
    • example of core plugins are: the Jar plugin, the Compiler plugin, the Surefire plugin
    • example of specialized plugins are: the Hibernate3 plugin

No comments :

Post a Comment