06 - Building with Maven

6. Building with Maven

            6.1 Build

                        6.1.1 Build lifecycles

                                     6.1.1.2 Clean

                                     6.1.1.3 Default

                                                6.1.1.3.1 Skip tests

                                    6.1.1.4 Site    

                        6.2 Build phases

                                    6.2.1 Validate

                                    6.2.2 Compile

                                    6.2.3 Test

                                    6.2.4 Package

                                    6.2.5 Install

                                    6.2.6 Deploy

            6.3 Build goals

            6.2 Build profiles

           

Maven is an open source tool for Java enterprise projects designed to make easier the build process. Once understood Maven helps to save time with all types of projects – small or big.

Maven carries out of repetitive tasks increasing the productivity. 

6.1 Build

Build is a process by which source code is converted in a stand-alone form that can be run on a computer. The most important part of a build is the compilation process where source code files are converted in executable code.

Building process is managed by a build tool. Builds are created when the code is ready for implementation, for testing or for release.

Building includes one of more of the following activities:

  • Source code generating (auto-generating code)
  • Documentation and release notes generating from source code
  • Compiling source code to binary code
  • Packaging of binary code
  • Running automated tests
  • Installing the packaged code on a server or in a repository

6.1.1 Build lifecycles

In Maven the process of building and distributing an artifact (project) is precisely defined. The process represents a central concept of Maven: build lifecycle.

For building there are necessary some commands to be learnt and with the help of the POM the build will drive to the desired results.

 Built-in Maven Lifecycles are: default, clean and site.

The build lifecycles are composed by build phases and a build phase represents a stage in a lifecycle. Phases give order to a set of goals. Goals are bound to phases. Goals that are not bound to the phases can be executed outside the build lifecycle by directly calling them.

Build phases are executed sequentially to complete a build lifecycle.

 6.1.1.2 Clean

Clean is the simplest lifecycle in Maven. It can be run with the command

        mvn clean

This lifecycle is composed of three lifecycle phases:

  • Pre-clean
  • Clean
  • Post-clean

              

After running clean Maven will delete the build directory. If the location of the build directory is not customized then this is ${basedir}/target directory defined by the Super POM.

6.1.1.3 Default

If the default lifecycle is applied for a project then the builds becomes automated.

The main phases of the default lifecycle are:

validate

validates the project information

compile

compiles the source code

test

test unit tests with a test framework

package

package code into distributable format (JAR)

integration-test

processes the package in the integration test environment where integration tests can be run

verify

runs checks to verify if package is valid

 install

installs the package in the local repository

deploy

installs the final package in the remote repository

6.1.1.3.1 Skip tests

Tests can be skipped by adding the argument -Dmaven.test.skip=true”in command line

     Mvn install –Dmaven.test.skip=true

     Mvn package –Dmaven.test.skip=true

In maven-surefire-plugin  defineskipTests tag:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.12.4</version>
    <configuration>
        <skipTests>true</skipTests>
    </configuration>
</plugin>

In Eclipse it can be checked the Skip Tests option from the window Run Configurations:

                

6.1.1.4 Site    

Maven site generator can create a project with professional quality and low maintenance. This kind of site is useful in a company for technical project information and team communication.

Maven sites are used on open source projects. A project site contains information about the project, some reports generated and project specific content.

This lifecycle contains the following phases

  • Pre-site
  • Site
  • Post-site
  • Site-deploy

It can be generated from command-line with the statement:

      mvn site

 

6.1.2 Build phases

Maven comes preconfigured with the build phases. If a phase is specified to be executed then all the phases up to this phase will be executed. For example if package phase is specified then Maven will run through the compile phase, then the test phase and finally the package phase.

6.1.2.1 Validate

Validate is a phase that control if the project is correct and all the information is available. It checks also if the dependencies are downloaded.

6.1.2.2 Compile

The compile phase is bind with the Compiler plugin’s compile goal in most of cases. This phase is called by the statement:

       compile:compile

and compiles the source code transforming it in byte code and copy then it to the output build directory.

If the SuperPOM is not customized then it will copy the compiled source code from src/main/java to target/classes directory.

In a web application the target directory can set in POM in the following way:

<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
    <configuration>
    <webResources>
    <resource>
<directory>${basedir}/src/main/webapp/WEB-INF</directory>
        <filtering>true</filtering>
        <targetPath>WEB-INF</targetPath>
        <includes>
<include>config.*.properties</include>
            </includes>
        </resource>
    </webResources>
</configuration>
</plugin>
</plugins>

The target directory can be changed also with profiles:

<profiles>
<profile>
<id>otherOutputDir</id>
<activation>
<property>
<name>yourDirectory</name>
</property>
</activation>
<build>
<directory>${yourDirectory}</directory>
</build>
</profile>
</profiles>

Changing the build directory to your Directory can be done in POM, in settings.xml or in command line. If the property is not set the compiled code will be transferred to the target directory.

6.1.2.3 Test

In order to execute the unit tests of an application Maven uses the Surefire Plugin. After runs:

             mvn test

It generates reports in 2 different file formats:

  • Plain text  (*.txt)
  • Xml files (*.xml)

The files are generated by default at ${basedir}/target/surefire-reports.

Surefire looks for classes ending in *Test in the test source directory and run them as JUnit tests. The plugin can be configured to run also TestNG unit tests.

Builds can be configured to continue if a failure produces.

<build>
    <plugins>
    <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
</configuration>
</plugin>
...
</plugins>
</build>

6.1.2.4 Package

This phase creates JAR/WAR/EAR package depending on the value mentioned in POM and put it in the target folder. From command line it can be run with:

       mvn package

           

If packaging is type jar:

<project...>
<groupId>com.myproject.example</groupId>
<artifactId>myproject-example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
</project>

or type war :

<project...>
<groupId>com.myproject.example</groupId>
<artifactId>myproject-example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
</project>
<project...>
<groupId>com.myproject.example</groupId>
<artifactId>myproject-example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
</project>

Or type pom :

<groupId>com.myproject.example</groupId>
<artifactId>myproject-example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
</project>
<groupId>com.myproject.example</groupId>
<artifactId>myproject-example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
</project>
<project...>
<groupId>com.myproject.example</groupId>
<artifactId>myproject-example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
</project>

Packaging of pom is usually used in projects that aggregate other projects and the top level POM (parent POM) must include the tag <modules>…</modules>.In this case POM file itself gets installed into the local Maven repository.

When package phase is executed then the phases validate, compile and test are executed orderly before this phase.

6.1.2.5 Install

This phase is part of the default build life cycle, which builds the project and copies the packaged JAR/WAR file into the Mavenlocalrepository and the project can be used then as a dependency. The command will execute all the build phases before install.

          mvn install

It can be combined with the clean build life cycle from the command line:

         mvn clean install

The clean build life cycle will remove all the compiled classes from the Maven output directory and then it will execute the install build phase.

6.1.2.6 Deploy

This is the last phase of the default lifecycle. Because is the last phase, all the previous phases of the lifecycle will be executed.

         mvn deploy

This phase install the final package in a remote repository for sharing with other developers and projects.

This phase should not be confused with maven release which will put the code in SCM and change the version of the project.

6.1.3 Build goals

Goals are the equivalents to the procedural tasks from Ant. Many Maven plugins bind specific goal (mojo) to a specific lifecycle phase.

For example:

       maven – jar – plugin : jar

This means the goal jar binds to the lifecycle phase: package.

A mix of plugin goals can be bind to a specific lifecycle phase.

A goal specified during a plugin execution will be bind to a given default phase. If the goal is specified during Maven execution then it will run all the phases to that goal. For example if jar goal is specified then it will runall the phases to the phase for that goal and then it will run the jar goal.

6.2 Build profiles

A project can be configured with Maven differently for different environments. Different instances will be generated depending on the target environment. In this scope a set of Maven profiles can be used: one profile for each environment.

For the test environment for example the test profile can be activated in order to get test configuration.

Different servers need to have a different configuration of the application. That could be different database connection configurations or logging configuration that should be visible only during development.

Using a profile for build does not means that the resulting artifact after build will be identical with the artifact that should result without profile.

The profiles can be created in POM.xml , for example if we want to create two profiles, one for development and one for production we have to add in POM.xml the following:

<project>
...
<profiles>
<profile>
<id>profile-dev</id>
<activation>
<activeByDefault>true</activeByDefault>
<property>
<name>environment</name>
<value>dev</value>
</property>
</activation>
</profile>
<profile>
<id>profile-prod</id>
<activation>
<property>
<name>environment</name>
<value>prod</value>
</property>
</activation>
</profile>
</profiles>
...
</project>

The id of the created profiles is represented by the name of the profiles. Inside of the tag activation there is the tag name that specify that the profile should be activated by the variable environment.  The variable can be passed to Maven while doing a new build.

For example:

       mvn clean compile package –Denvironment=prod

In order to check which profile is currently active it has to be used the following command:

       mvn clean compile package –Denvironment=prodhelp:active-profiles

In the console will be displayed the result:

[INFO]
Active Profiles for Project 'com.myarchetype:archetype-example:jar:1.0-SNAPSHOT':
The following profiles are active:
 - profile-prod (source: com.myarchetype:archetype-example:1.0-SNAPSHOT)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23.653 s
[INFO] Finished at: 2014-10-17T00:29:47+03:00
[INFO] Final Memory: 12M/30M
[INFO] ------------------------------------------------------------------------

 

In eclipse the profile can be declared in the window Run Configuration:

                

 

If the profile applies only for a module then in the properties of the module the profile has to be specified too (right click in Eclipse on the Module then select Properties):

               

If a profile is used to exclude some folders at deployment in production environment then this has to be configured with the tag <packagingExcludes>in POM file.

<project>
….
<profiles>
    <profile>
        <id>profile-prod</id>
        <activation>
        <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <plugins>
                <plugin>
                <artifactId>archetype-example</artifactId>
                    <configuration>                    <packagingExcludes>WEB-INF/cms</packagingExcludes>
                    </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
<profiles>
…
</project>

Like us on Facebook