Apache Maven

Maven encompasses a set of build standards, an artifact repository model, and a software engine that manages and describes projects. It defines a standard life cycle for building, testing, and deploying project artifacts.

“Maven is a declarative project management tool that decreases your overall time to market by effectively leveraging cross-project intelligence. It simultaneously reduces your duplication effort and leads to higher code quality.”

To summarize: Maven is many things to many people. It is a set of standards and an approach to project development. Maven is a collection of highly-interdependent components, which can be described in a common format.

It is the next step in the evolution of how individuals and organizations collaborate to create software systems.

1.1 Maven’s Origins

Maven was borne of the practical desire to make several projects at the Apache Software Foundation(ASF) work in the same, predictable way. Prior to Maven, every project at the ASF had a different approach to compilation, distribution, and Web site generation. The ASF was effectively a series of isolated islands of innovation. While there were some common themes across the separate builds, each community was creating its own build systems and there was no reuse of build logic across projects. The build process for Tomcat was different than the build process for Struts, and the Turbine developers had a different site generation process than the Jakarta Commons developers.

This lack of a common approach to building software meant that every new project tended to copy and paste another project’s build system. Ultimately, this copy and paste approach to build reuse reached a critical tipping point at which the amount of work required to maintain the collection of build systems was distracting from the central task of developing high-quality software.

Once developers spent time learning how one project was built, they did not have to go through the process again when they moved on to the next project. Developers at the ASF stopped figuring out creative ways to compile, test, and package software, and instead, started focusing on component development. The same standards extended to testing, generating documentation, generating metrics and reports, and deploying.

Like Maven Apache Ant is also a software tool for automating software build processes. It originally came from the Apache Tomcat project in early 2000.

History of Apache Ant

Ant was created by James Duncan Davidson (the original author of Tomcat).
It was originally used to build Tomcat, and was bundled as a part of Tomcat distribution.
Ant was born out of the problems and complexities associated with the Apache Make tool.
Ant was promoted as an independent project in Apache in the year 2000. The latest version of Apache Ant as on May 2014 is 1.9.4.

Features of ANT

Ant is the most complete Java build and deployment tool available.
Ant is platform neutral and can handle platform specific properties such as file separators.
Ant can be used to perform platform specific tasks such as modifying the modified time of a file using ‘touch’ command.
Ant scripts are written using plain XML. If you are already familiar with XML, you can learn Ant pretty quickly.
Ant is good at automating complicated repetitive tasks.
Ant comes with a big list of predefined tasks.
Ant provides an interface to develop custom tasks.
Ant can be easily invoked from the command line and it can integrate with free and commercial IDEs.

Hence Ant provides a toolbox for scripting builds, Maven provides standards and a set of patterns in order to facilitate project management through reusable, common build strategies.

1.2 Comparison of Maven with Apache ANT:

Major differences between Maven and ANT are:

Maven is description of a project whereas ANT is development of a build script per project.
Maven follows conventions like a common project directory structure whereas ANT needs to be told about the exactly where to find the source and where to put the output.
Maven has invocation of defined goals (targets) whereas in ANT script you have invocation of project specific targets.
Maven has build life cycle, standard project layout where as ANT doesn’t and it has too complex scripts(You have to define goals and goal dependencies). You have to attach a sequence of tasks to each goal manually.
Maven has reusable plugins, repositories whereas ANT scripts are not reusable.
Maven is declarative. All you have to do is create a pom.xml file and put your source in the default directory. Maven takes care of the rest.ANT is procedural which means you need to tell it to compile, copy and then compress.

1.3 Maven’s Principles

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

Convention over configuration

Maven uses Convention over Configuration which means developers are not required to create build process themselves.

Developers do not have to mention each and every configuration detail. When a Maven project is created, Maven creates default project structure. Developer is only required to place files accordingly and he/she need not to define any configuration in pom.xml.

Declarative execution

Everything in Maven is driven in a declarative fashion using Maven’s Project Object Model (POM) and specifically, the plugin configurations contained in the POM. The execution of Maven’s plugins is coordinated by Maven’s build life cycle in a declarative fashion with instructions from Maven’s POM.

Reuse of build logic

Maven promotes reuse by encouraging a separation of concerns (SoC). Maven puts this SoC principle into practice by encapsulating build logic into coherent modules called plugins.
In Maven there is a plugin for compiling source code, a plugin for running tests, a plugin for creating JARs, a plugin for creating Javadocs, and many other functions . Plugins are the key building blocks for everything in Maven.

Coherent organization of dependencies

In Java, the most common artifact is a JAR file, but a Java artifact could also be a WAR, SAR, or EAR file. A dependency is a reference to a specific artifact that resides in a repository. A dependency is uniquely identified by the following identifiers: groupId, artifactId and version.

When a dependency is declared within the context of your project, Maven tries to satisfy that dependency by looking in all of the remote repositories to which it has access, in order to find the artifacts that most closely match the dependency request. If a matching artifct is located, Maven transports it from that remote repository to your local repository for project use.

1.4 Key features of Maven

Simple Maven project that follow Best practices required for Real time project.
Automate the build process – Compile, Package JAR/WAR, Deploy war in Server, Generate Report
Transitive dependencies (Inter dependency ex: To include commons-lang jar, it may again dependent on log4j jar, maven will automatically download the jar and include)
Dependency management: Maven encourages the use of a central repository of JARs and other dependencies
Extensible, with the ability to easily write plugins. Many plugins are developed to support compiling source code, deploying the war from work space to server, generate the report, generating stubs for web-service.
Build profiling – This feature will helps when we want to deploy the same code base in different environment such as DEV, QA , STAGE , PRE-PROD, PROD and we need to modify the Data Base URL, Third party URLS which are environmental dependent.
Maven supports multi-module project for re-usability of Module for different Project.Example: Common Façade & Service for Multiple Web Application, Common POM holding the Jar for Multiple Project to avoid duplication of jar etc.

1.5 Maven’s project object model (POM)

Maven is project-centric by design, and the POM is Maven’s description of a single project. Without the POM, Maven is useless – the POM is Maven’s currency. It is the POM that drives execution in maven and this approach can be described as model-driven or declarative execution.

The POM contains every important piece of information about your project. POM contains.

project – This is the top-level element in all Maven pom.xml files.
modelVersion – This required element indicates the version of the object model that the POM is using. The version of the model itself changes very infrequently, but it is mandatory in order to ensure stability when Maven introduces new features or other model changes.
groupId – This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plugins.
artifactId – This element indicates the unique base name of the primary artifact being generated by this project. A typical artifact produced by Maven would have the form < artifactId >- <version> . <extension> (for example, myapp-1.0.jar ). Additional artifacts such as source bundles also use the artifactId as part of their file name.
packaging – This element indicates the package type to be used by this artifact (JAR,WAR, EAR, etc.). This not only means that the artifact produced is a JAR, WAR, or EAR, but also indicates a specific life cycle to use as part of the build process. The life cycle is a topic dealt with later in this chapter. For now, just keep in mind that the selected packaging of a project plays a part in customizing the build life cycle. The default value for the packaging element is jar so you do not have to specify this in most cases.
version – This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development.
name – This element indicates the display name used for the project. This is often used in Maven’s generated documentation, and during the build process for your project, or other projects that use it as a dependency.
url – This element indicates where the project’s site can be found.
description – This element provides a basic description of your project.

For a complete reference of the elements available for use in the POM please refer to the POM reference at http://maven.apache.org/maven-model/maven.html.

1.6 Maven Build Life Cycles, Phases and Goals

Maven has following three standard lifecycles:

clean
default(or build)
site

A Maven plugin is a collection of one or more goals. A goal is a “unit of work” in Maven.

A goal represents a specific task which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.

The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The clean and package arguments are build phases while the dependency:copy-dependencies is a goal.

mvn clean dependency:copy-dependencies package

Here the clean phase will be executed first, and then the dependency:copy-dependencies goal will be executed, and finally package phase will be executed.

Maven builds life cycle phases.

The following lists all build phases of the default, clean and site lifecycle, which are executed in the order given up to the point of the one specified.

Clean Lifecycle

pre-clean

executes processes needed prior to the actual project cleaning

clean

remove all files generated by the previous build

post-clean

executes processes needed to finalize the project cleaning

Default Lifecycle

validate	validate the project is correct and all necessary information is available.
initialize	initialize build state, e.g. set properties or create directories.
generate-sources	generate any source code for inclusion in compilation.
process-sources	process the source code, for example to filter any values.
generate-resources	generate resources for inclusion in the package.
process-resources	copy and process the resources into the destination directory, ready for packaging.
compile	compile the source code of the project.
process-classes	post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources	generate any test source code for inclusion in compilation.
process-test-sources	process the test source code, for example to filter any values.
generate-test-resources	create resources for testing.
process-test-resources	copy and process the resources into the test destination directory.
test-compile	compile the test source code into the test destination directory
process-test-classes	post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test	run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package	perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package	take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test	perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test	process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test	perform actions required after integration tests have been executed. This may including cleaning up the environment.
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.

Site Lifecycle

pre-site	executes processes needed prior to the actual project site generation
Site	generates the project's site documentation
post-site	executes processes needed to finalize the site generation, and to prepare for site deployment
site-deploy	deploys the generated site documentation to the specified web server

December 31, 2015

What is Maven and how do I install it?

1 what is maven?

1.1 Maven’s Origins

History of Apache Ant

Features of ANT

1.2 Comparison of Maven with Apache ANT:

1.3 Maven’s Principles

1.4 Key features of Maven

1.5 Maven’s project object model (POM)

1.6 Maven Build Life Cycles, Phases and Goals

Maven builds life cycle phases.

0 responses on "Apache Maven"

Leave a Message Cancel reply

Free Course Spring Framework Fundamentalsby admin

Free Course Java 8 Lambdas & Streamsby Madhusudhan

PradeepIT Fresher Assessment Program | MBA in HR & Marketingby Vinod