Build Tool - Maven Information

What is Build Tool

A build tool takes care of everything for building a process. It does following:

• Generates source code (if auto-generated code is used)
• Generates documentation from source code
• Compiles source code
• Packages compiled code into JAR of ZIP file
• Installs the packaged code in local repository, server repository, or central repository
• Required jar files will be downloaded by buildtool to your project

Build Tools in the Market?

 1)Ant

2)Maven

3)Gradle

Difference between Ant and Maven

Ant and Maven both are build tools provided by Apache. The main purpose of these technologies is to ease the build process of a project.

There are many differences between ant and maven that are given below:

Ant	Maven
Ant doesn't has formal conventions, so we need to provide information of the project structure in build.xml file.	Maven has a convention to place source code, compiled code etc. So we don't need to provide information about the project structure in pom.xml file.
Ant is procedural, you need to provide information about what to do and when to do through code. You need to provide order.	Maven is declarative, everything you define in the pom.xml file.
There is no life cycle in Ant.	There is life cycle in Maven.
It is a tool box.	It is a framework.
It is mainly a build tool.	It is mainly a project management tool.
The ant scripts are not reusable.	The maven plugins are reusable.
It is less preferred than Maven.	It is more preferred than Ant.

 

What is Maven?

Maven is a powerful project management and comprehension tool that is based on POM (project object model).

Maven provides developers a complete build lifecycle framework. Development team can automate the project's build infrastructure in almost no time as Maven uses a standard directory layout and a default build lifecycle.

It is used for projects build, dependency and documentation.

It simplifies the build process like ANT. But it is too much advanced than ANT.

Current version of Maven is 3.x.0(3.6.3)

MAVEN ADVANTAGES:

Ø  Maven makes a project easy to build

Ø  It provides uniform build process (maven project can be shared by all the maven projects)

Ø  It provides project information (log document, cross referenced sources, mailing list, dependency list, unit test reports etc.)

Ø  It is easy to migrate for new features of Maven

Apache Maven helps to manage

Ø  Builds

Ø  Documentation

Ø  Reporing

Ø  SCMs

Ø  Releases

Ø  Distribution

POM stands for Project Object Model. It is fundamental Unit of Work in Maven. It is an XML file. It always resides in the base directory of the project as pom.xml.

·        All POM files require the project element and three mandatory fields: groupId, artifactId,version.

·        Projects notation in repository is groupId:artifactId:version.

·        Root element of POM.xml is project and it has three major sub-nodes :

Node	Description
groupId	This is an Id of project's group. This is generally unique amongst an organization or a project. For example, a banking group com.company.bank has all bank related projects.
artifactId	This is an Id of the project.This is generally name of the project. For example, consumer-banking. Along with the groupId, the artifactId defines the artifact's location within the repository.
version	This is the version of the project.Along with the groupId, It is used within an artifact's repository to separate versions from each other. For example:  com.company.bank:consumer-banking:1.0 com.company.bank:consumer-banking:1.1.

Why Maven & Jenkins

Selenium WebDriver is great for browser automation. But, when using it for testing and building a test framework, it feels underpowered. Integrating Maven with Selenium provides following benefits
Apache Maven provides support for managing the full lifecycle of a test project.

• Maven is used to define project structure, dependencies, build, and test management.
• Using pom.xml(Maven) you can configure dependencies needed for building testing and running code.
• Maven automatically downloads the necessary files from the repository while building the project.

Maven Dependency Scopes

1. Introduction

Maven is one of the most popular build tools in the Java ecosystem, and one of its core features is dependency management.

In this article, we’re going to describe and explore the mechanism that helps in managing transitive dependencies in Maven projects – dependency scopes.

2. Transitive Dependency

Simply put, there’re two types of dependencies in Maven direct and transitive.

Direct dependencies are the ones that are explicitly included in the project. These can be included in the project using <dependency> tags:

1 2 3 4 5

<dependency>     <groupId>junit</groupId>     <artifactId>junit</artifactId>     <version>4.12</version> </dependency>

Transitive dependencies, on the other hand, are dependencies required by our direct dependencies. Required transitive dependencies are automatically included in our project by Maven.

We can list all dependencies including transitive dependencies in the project using: mvn dependency:tree command.

3. Dependency Scopes

Dependency scopes can help to limit transitivity of the dependencies and they modify classpath for different built tasks. Maven has 6 default dependency scopes.

And it’s important to understand that each scope – except for import – does have an impact on transitive dependencies.

3.1. Compile

This is the default scope when no other scope is provided.

Dependencies with this scope are available on the classpath of the project in all build tasks and they’re propagated to the dependent projects.

More importantly, these dependencies are also transitive:

1 2 3 4 5

<dependency>     <groupId>commons-lang</groupId>     <artifactId>commons-lang</artifactId>     <version>2.6</version> </dependency>

3.2. Provided

This scope is used to mark dependencies that should be provided at runtime by JDK or a container, hence the name.

A good use case for this scope would be a web application deployed in some container, where the container already provides some libraries itself.

For example, a web server that already provides the Servlet API at runtime, thus in our project, those dependencies can be defined with the provided scope:

1 2 3 4 5 6

<dependency>     <groupId>javax.servlet</groupId>     <artifactId>servlet-api</artifactId>     <version>2.5</version>     <scope>provided</scope> </dependency>

The provided dependencies are available only at compile-time and in the test classpath of the project; what’s more, they aren’t transitive.

3.3. Runtime

The dependencies with this scope are required at runtime, but they’re not needed for compilation of the project code. Because of that, dependencies marked with the runtimescope will be present in runtime and test classpath, but they will be missing from compile classpath.

A good example of dependencies that should use the runtime scope is a JDBC driver:

1 2 3 4 5 6

<dependency>     <groupId>mysql</groupId>     <artifactId>mysql-connector-java</artifactId>     <version>6.0.6</version>     <scope>runtime</scope> </dependency>

3.4. Test

This scope is used to indicate that dependency isn’t required at standard runtime of the application, but is used only for test purposes. Test dependencies aren’t transitive and are only present for test and execution classpaths.

The standard use case for this scope is adding test library like JUnit to our application:

1 2 3 4 5 6

<dependency>     <groupId>junit</groupId>     <artifactId>junit</artifactId>     <version>4.12</version>     <scope>test</scope> </dependency>

3.5. System

System scope is much similar to the provided scope. The main difference between those two scopes is that system requires us to directly point to specific jar on the system.

The important thing to remember is that building the project with system scope dependencies may fail on different machines if dependencies aren’t present or are located in a different place than the one systemPath points to:

1 2 3 4 5 6 7

<dependency>     <groupId>com.baeldung</groupId>     <artifactId>custom-dependency</artifactId>     <version>1.3.2</version>     <scope>system</scope>     <systemPath>${project.basedir}/libs/custom-dependency-1.3.2.jar</systemPath> </dependency>

3.6. Import

This scope was added in Maven 2.0.9 and it’s only available for the dependency type pom.We’re going to speak more about the type of the dependency in future articles.

Import indicates that this dependency should be replaced with all effective dependencies declared in it’s POM:

1 2 3 4 5 6 7

<dependency>     <groupId>com.baeldung</groupId>     <artifactId>custom-project</artifactId>     <version>1.3.2</version>     <type>pom</type>     <scope>import</scope> </dependency>

4. Scope and Transitivity

Each dependency scope affects transitive dependencies in its own way. This means that different transitive dependencies may end up in the project with different scopes.

However, dependencies with scopes provided and test will never be included in the main project.

Then:

• For the compile scope, all dependencies with runtime scope will be pulled in with the runtime scope, in the project and all dependencies with the compile scope will be pulled in with the compile scope, in the project
• For the provided scope, both runtime and compile scope dependencies will be pulled in with the provided scope, in the project
• For the test scope, both runtime and compile scope transitive dependencies will be pulled in with the test scope, in the project
• For the runtime scope, both runtime and compile scope transitive dependencies will be pulled in with the runtime scope, in the project

Some important Maven commands.

• mvn clean – This command is used to clean the project’s target directory.

• mvn compile – This command is used to compile the source code of the project.

• mvn package – This command is used to package the project into a JAR file.

• mvn install – This command is used to install the package into the local repository.

• mvn deploy – This command is used to deploy the package to a remote repository.

• mvn test – This command is used to run the unit tests of the project.

• mvn verify – This command is used to run the integration tests of the project.

• mvn site – This command is used to generate the project’s site documentation.

• mvn help:effective-pom – This command is used to display the effective POM of the project.

• mvn help:describe – This command is used to display the details of a mojo.

• mvn archetype:generate – This command is used to generate a project from an archetype.

• mvn help:active-profiles – This command is used to list the active profiles in the project.

• mvn dependency:tree – This command is used to display the project's dependency tree.

• mvn help:plugin – This command is used to display information about a specific plugin.

• mvn help:system – This command is used to display information about the system.

• mvn help:effective-settings – This command is used to display the effective settings of the project.

• mvn help:describe – This command is used to display information about a specific mojo.

• mvn clean test – This command is used to clean the project and then run the unit tests.

• mvn site:run – This command is used to generate the project’s site documentation and launch a web server to view it.

• mvn help:all-profiles – This command is used to list all the profiles in the project.

• mvn dependency:analyze – This command is used to analyze the project’s dependencies.

• mvn help:system-properties – This command is used to display system properties that can be used in the project.

• mvn help:evaluate – This command is used to evaluate an expression in the project’s POM.

• mvn help:descriptor – This command is used to display the project descriptor.

• mvn help:active-profiles – This command is used to list the active profiles in the project.

• mvn help:plugin-prefix – This command is used to display the list of available plugin prefixes.