Contents

DevOps – Build Tools...........................................................................................................................2

Overview of Various Build Tools.............................................................................................................3
What is Mavan..........................................................................................................................................9
Maven Plugins.........................................................................................................................................12
Maven Archetypes..................................................................................................................................21
Project Object Model (POM).................................................................................................................28
Source Control Integration.....................................................................................................................40
DevOps – Build Tools
Overview of Various Build Tools
https://www.plutora.com/ci-cd-tools/software-build-tools

Software build tools are used to automate the creation of executable applications from source
code. They script or automate a variety of tasks, such as downloading dependencies, compiling
and packaging code, running tests, and deployment. They can be triggered through the
command line, inside an IDE, or by continuous integration tools after checking the code out of a
repository and onto a build machine. Different build systems exist for different languages.
Usually, build systems use either a domain-specific language or XML to specify a build.

There are three types of build processes that enable developers to get their software builds
done:

1. Continuous Integration (CI) builds: In this practice, developers merge their code to a
centralized mainline several times a day. This prevents integration problems with incompatible
or buggy code when all of the developers attempt to check in at the last minute prior to a
release. While deployments involve simply preparing the code so it can be run, CI builds involve
running the code against a test suite.
2. Gated check-in builds: Also known as gated commits, this is a software integration pattern
where developers must request a gated commit from the CI server before committing the
changes to the shared mainline. That way, they can observe whether the changes break the
build before actually committing them.
3. Nightly builds: Also referred to as scheduled builds, the name pretty much describes the
process. Builds are done at a scheduled time on a daily basis. This process usually occurs at
night so that the code can be compiled by the build computer during off hours, then tested by
developers the following morning.

In this section, we will generally be referring to CI builds and, to a lesser extent, gated check-in
builds.

What are Software Build Tools?

Modern build automation tools don’t just compile code; they enable workflows by obtaining
source code, deploying executables to be tested, and optimizing complex build processes.
There are numerous build tools with all sorts of trade-offs between them, but usually they are
based on a specific language. For an example, Maven and Ant are XML-based tools, Grunt is
JSON-based, and sbt is Scala-based.

Build tool features might include: running ad-hoc commands, ordering the execution of
commands based on dependencies, parallelizing different commands, overseeing file changes
and running commands based on those changes, using external processes such as compilers,
allowing configuration and re-configuration, and downloading dependencies.

Benefits of Software Build Tools

Build automation tools are crucial for moving towards a continuous delivery (CD) model. They
allow you to build your project with the click of a button, which reduces errors from manually
running steps, and also increases the consistency of the process. Automated builds make sure
that the whole team knows almost immediately when something goes wrong, and who is
responsible for the error. They are especially important in environments with multiple
interdependent projects, helping to ensure that people don’t break anything when working
concurrently on different projects. In addition, outside groups (such as marketing and beta
customer sites) can pick a stable build and use it while the product or feature is still in progress.

When combined with a solid source control system, build tools allow developers to maintain an
archive of builds so that they can backtrack and identify when a bug first appeared in the
system. This improves communication and transparency in an organization. Some build tools
can even capture metrics for code coverage, code complexity, and features complete that help
developers to control code quality and track efficiency.

Add testing to the equation, and you’ll gain the ability to always know the state of your software.
That way, you can safely decide whether or not to deploy to production without worrying about
unforeseen bugs.

Best Software Build Tools

Leiningen

Leiningen is a build tool for Clojure. It serves as an adapter between the command line
and Clojure, making it easier for you to run Clojure functions.
Packer

HashiCorp Packer is a free and open source tool for creating identical machine images
for multiple platforms from a single source configuration. Its advantages include: faster
infrastructure deployment, multi-provider portability, improved stability, and greater
testability.

Gulp

Gulp is a JavaScript task runnner that automates painful or time-consuming tasks in your
development workflow, such as: bundling and minifying libraries and stylesheets,
running unit tests, and running code analysis. Its purpose and features are very similar
to those of Grunt.

NAnt

NAnt is a free and open source build automation tool similar to Apache Ant, but targeted
at the .NET environment instead of Java. It can perform tasks such as compiling source
code and resource files into assemblies, running unit tests, configuring build-specific
settings, and more.

Grunt

Grunt is a JavaScript task runner that automates repetitive tasks like minification,
compilation, unit testing, and linting. It also has a large ecosystem of plugins that extend
base functionality.

Ant

Apache Ant is one of the more venerable Java-based build automation tools, originating
from the Apache Tomcat project in 2000. Its strengths are portability, flexibility, and
simplicity. It does not impose coding conventions or project structures, and its build files
can easily be transferred to other platforms because they inherit the Java platform’s
independence. By the same token, Ant files can be difficult to understand and grasp
immediately.
 Ant does not have built-in support for dependency management; rather, Ant’s
dependency management is handled by Apache Ivy, a sub-project that integrates with
Ant.

Maven

Apache Maven is a dependency management and build automation tool from the
Apache Software Foundation. Based on the concept of a project object model (POM),
Maven can manage a project’s build, reporting and documentation from a central piece
of information. It uses XML to configure projects and Java to write extensions.

Maven emerged as a result of various frustrations with Ant. Like Ant, it uses XML for
project configuration, but with more conventions and predefined commands that provide
a framework in which to work. It also has built-in dependency management, which Ant
lacks.

Docker

Docker is a software container platform. Originally released in 2013 as an open source

Docker Engine, it has grown enormously in popularity and now has an integral place in
most DevOps toolchains. It enables developers to easily pack, ship, and run any
application as a lightweight, portable, self-sufficient container, which can run almost
anywhere. This eliminates “works on my machine” problems when collaborating on
code, ensuring that applications work seamlessly in any environment.

Docker containers are the preferred replacement for Virtual Machines (VMs), given that
they boot faster, perform better, and consume less memory resources. Docker
Containers are also able to share a single kernel and share application libraries.

Gradle

Gradle Build Tool is an open source build automation system designed for multi-project
builds. It supports Maven and Ivy repositories for retrieving dependencies so that you
can reuse artifacts of existing build systems.
 Essentially, Gradle was built to combine the best parts of established tools like Ant and
Maven, but with a Groovy-based Domain Specific Language (DSL) instead of XML for
declaring project configuration. DSL tends to be easier to read, more succinct, and also
more powerful.

Gradle is the official build tool for Android Studio.

SBT

Simple Build Tool (SBT) by Scala is an open-source build tool for Java and Scala
projects. Its features include incremental compilation and an interactive shell.
What is Mavan
https://maven.apache.org/plugins/index.html
Introduction
Maven, a Yiddish word meaning accumulator of knowledge, began as an attempt to simplify the
build processes in the Jakarta Turbine project. There were several projects, each with their own
Ant build files, that were all slightly different. JARs were checked into CVS. We wanted a
standard way to build the projects, a clear definition of what the project consisted of, an easy
way to publish project information, and a way to share JARs across several projects.
The result is a tool that can now be used for building and managing any Java-based project. We
hope that we have created something that will make the day-to-day work of Java developers
easier and generally help with the comprehension of any Java-based project.
Maven’s Objectives
Maven’s primary goal is to allow a developer to comprehend the complete state of a
development effort in the shortest period of time. In order to attain this goal, Maven deals with
several areas of concern:

 Making the build process easy

 Providing a uniform build system
 Providing quality project information
 Encouraging better development practices

Making the build process easy

While using Maven doesn’t eliminate the need to know about the underlying mechanisms,
Maven does shield developers from many details.
Providing a uniform build system
Maven builds a project using its project object model (POM) and a set of plugins. Once you
familiarize yourself with one Maven project, you know how all Maven projects build. This saves
time when navigating many projects.
Providing quality project information
Maven provides useful project information that is in part taken from your POM and in part
generated from your project’s sources. For example, Maven can provide:

 Change log created directly from source control

 Cross referenced sources
 Mailing lists managed by the project
 Dependencies used by the project
 Unit test reports including coverage

Third party code analysis products also provide Maven plugins that add their reports to the
standard information given by Maven.
Providing guidelines for best practices development
Maven aims to gather current principles for best practices development and make it easy to
guide a project in that direction.
For example, specification, execution, and reporting of unit tests are part of the normal build
cycle using Maven. Current unit testing best practices were used as guidelines:

 Keeping test source code in a separate, but parallel source tree

 Using test case naming conventions to locate and execute tests
 Having test cases setup their environment instead of customizing the build for test
preparation

Maven also assists in project workflow such as release and issue management.
Maven also suggests some guidelines on how to layout your project’s directory structure. Once
you learn the layout, you can easily navigate other projects that use Maven.
While takes an opinionated approach to project layout, some projects may not fit with this
structure for historical reasons. While Maven is designed to be flexible to the needs of different
projects, it cannot cater to every situation without compromising its objectives.
If your project has an unusual build structure that cannot be reorganized, you may have to forgo
some features or the use of Maven altogether.
What is Maven Not?
You might have heard some of the following things about Maven:

 Maven is a site and documentation tool

 Maven extends Ant to let you download dependencies
 Maven is a set of reusable Ant scriptlets

While Maven does these things, as you can read above in the “What is Maven?” section, these
are not the only features Maven has, and its objectives are quite different.

Feature Summary
The following are the key features of Maven in a nutshell:

 Simple project setup that follows best practices - get a new project or module started
in seconds
 Consistent usage across all projects - means no ramp up time for new developers
coming onto a project
 Superior dependency management including automatic updating, dependency
closures (also known as transitive dependencies)
 Able to easily work with multiple projects at the same time
 A large and growing repository of libraries and metadata to use out of the box, and
arrangements in place with the largest Open Source projects for real-time availability
of their latest releases
 Extensible, with the ability to easily write plugins in Java or scripting languages
 Instant access to new features with little or no extra configuration
 Ant tasks for dependency management and deployment outside of Maven
 Model based builds: Maven is able to build any number of projects into predefined
output types such as a JAR, WAR, or distribution based on metadata about the
project, without the need to do any scripting in most cases.
 Coherent site of project information: Using the same metadata as for the build
process, Maven is able to generate a web site or PDF including any documentation
you care to add, and adds to that standard reports about the state of development of
the project. Examples of this information can be seen at the bottom of the left-hand
navigation of this site under the "Project Information" and "Project Reports"
submenus.
 Release management and distribution publication: Without much additional
configuration, Maven will integrate with your source control system (such as
Subversion or Git) and manage the release of a project based on a certain tag. It can
also publish this to a distribution location for use by other projects. Maven is able to
publish individual outputs such as a JAR, an archive including other dependencies
and documentation, or as a source distribution.
 Dependency management: Maven encourages the use of a central repository of
JARs and other dependencies. Maven comes with a mechanism that your project's
clients can use to download any JARs required for building your project from a
central JAR repository much like Perl's CPAN. This allows users of Maven to reuse
JARs across projects and encourages communication between projects to ensure
that backward compatibility issues are dealt with.
Maven Plugins
https://maven.apache.org/guides/introduction/introduction-to-plugins.html#:~:text=Plugins
%20are%20the%20central%20feature,Project%20Object%20Model%20(POM).
Maven consists of a core engine which provides basic project-processing capabilities and build-
process management, and a host of plugins which are used to execute the actual build tasks.
What is a Plugin?
"Maven" is really just a core framework for a collection of Maven Plugins. In other words, plugins
are where much of the real action is performed, plugins are used to: create jar files, create war
files, compile code, unit test code, create project documentation, and on and on. Almost any
action that you can think of performing on a project is implemented as a Maven plugin.
Plugins are the central feature of Maven that allow for the reuse of common build logic across
multiple projects. They do this by executing an "action" (i.e. creating a WAR file or compiling unit
tests) in the context of a project's description - the Project Object Model (POM). Plugin behavior
can be customized through a set of unique parameters which are exposed by a description of
each plugin goal (or Mojo).
One of the simplest plugins in Maven is the Clean Plugin. The Maven Clean plugin (maven-
clean-plugin) is responsible for removing the target directory of a Maven project. When you run
"mvn clean", Maven executes the "clean" goal as defined in the Clean plug-in, and the target
directory is removed. The Clean plugin defines a parameter which can be used to customize
plugin behavior, this parameter is called outputDirectory and it defaults to $
{project.build.directory}.
What is a Mojo (And Why the H--- is it Named 'Mojo')?
A Mojo is really just a goal in Maven, and plug-ins consist of any number of goals (Mojos).
Mojos can be defined as annotated Java classes or Beanshell script. A Mojo specifies metadata
about a goal: a goal name, which phase of the lifecycle it fits into, and the parameters it is
expecting.
MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also
an interesting word (see definition). From Wikipedia, a "mojo" is defined as: "...a small bag worn
by a person under the clothes (also known as a mojo hand). Such bags were thought to have
supernatural powers, such as protecting from evil, bringing good luck, etc."
In Maven, there are two kinds of plugins, build and reporting:

 Build plugins are executed during the build and configured in

the  <build/>  element.
 Reporting plugins are executed during the site generation and configured in
the  <reporting/>  element.

All plugins should have minimal required information:  groupId ,  artifactId  and  version .

https://maven.apache.org/plugins/index.html
Available Plugins
Maven is - at its heart - a plugin execution framework; all work is done by plugins. Looking for a
specific goal to execute? This page lists the core plugins and others. There are the build and the
reporting plugins:

 Build plugins will be executed during the build and they should be configured in
the  <build/>  element from the POM.
 Reporting plugins will be executed during the site generation and they should be
configured in the  <reporting/>  element from the POM. Because the result of a
Reporting plugin is part of the generated site, Reporting plugins should be both
internationalized and localized. You can read more about the localization of our
plugins and how you can help.

Supported By The Maven Project

To see the most up-to-date list browse the Maven repository, specifically
the  org/apache/maven/plugins  subfolder. (Plugins are organized according to a directory
structure that resembles the standard Java package naming convention)

Plugin Type* Version Description

Core Plugins corresponding to default core phases (ie. clean, compile).

plugins They may have multiple goals as well.

clean B 3.1.0 Clean up after the build.

compiler B 3.8.1 Compiles Java sources.

deploy B 3.0.0- Deploy the built artifact to the remote repository.

M1

failsafe B 3.0.0- Run the JUnit integration tests in an isolated classloader.

M5

install B 3.0.0- Install the built artifact into the local repository.
 M1

resources B 3.2.0 Copy the resources to the output directory for including in the JAR.

site B 3.9.1 Generate a site for the current project.

surefire B 3.0.0- Run the JUnit unit tests in an isolated classloader.

M5

verifier B 1.1 Useful for integration tests - verifies the existence of certain conditions.

Packaging These plugins relate to packaging respective artifact types.

types/tools

ear B 3.2.0 Generate an EAR from the current project.

ejb B 3.1.0 Build an EJB (and optional client) from the current project.

jar B 3.2.0 Build a JAR from the current project.

rar B 2.4 Build a RAR from the current project.

war B 3.3.1 Build a WAR from the current project.

app- B 3.1.0 Build a JavaEE application client from the current project.
client/acr

shade B 3.2.4 Build an Uber-JAR from the current project, including dependencies.
source B 3.2.1 Build a source-JAR from the current project.

jlink B 3.1.0 Build Java Run Time Image.

jmod B 3.0.0- Build Java JMod files.

alpha-1

Reporting Plugins which generate reports, are configured as reports in the

plugins POM and run under the site generation lifecycle.

changelog R 2.3 Generate a list of recent changes from your SCM.

changes B+R 2.12.1 Generate a report from an issue tracker or a change document.

checkstyle B+R 3.1.2 Generate a Checkstyle report.

doap B 1.2 Generate a Description of a Project (DOAP) file from a POM.

docck B 1.1 Documentation checker plugin.

javadoc B+R 3.3.0 Generate Javadoc for the project.

jdeps B 3.1.2 Run JDK's JDeps tool on the project.

jxr R 3.1.1 Generate a source cross reference.

linkcheck R 1.2 Generate a Linkcheck report of your project's documentation.

pmd B+R 3.14.0 Generate a PMD report.

project-info- R 3.1.2 Generate standard project reports.

reports

surefire- R 3.0.0- Generate a report based on the results of unit tests.

report M5

Tools These are miscellaneous tools available through Maven by default.

antrun B 3.0.0 Run a set of ant tasks from a phase of the build.

artifact B 3.1.0 Manage artifacts tasks like buildinfo.

archetype B 3.2.0 Generate a skeleton project structure from an archetype.

assembly B 3.3.0 Build an assembly (distribution) of sources and/or binaries.

dependenc B+R 3.2.0 Dependency manipulation (copy, unpack) and analysis.

y

enforcer B 3.0.0- Environmental constraint checking (Maven Version, JDK etc), User
 M3 Custom Rule Execution.

gpg B 3.0.1 Create signatures for the artifacts and poms.

help B 3.2.0 Get information about the working environment for the project.

invoker B+R 3.2.2 Run a set of Maven projects and verify the output.

jarsigner B 3.0.0 Signs or verifies project artifacts.

jdeprscan B 3.0.0- Run JDK's JDeprScan tool on the project.

alpha-1

patch B 1.2 Use the gnu patch tool to apply patch files to source code.

pdf B 1.4 Generate a PDF version of your project's documentation.

plugin B+R 3.6.1 Create a Maven plugin descriptor for any mojos found in the source tree,
to include in the JAR.

release B 3.0.0- Release the current project - updating the POM and tagging in the SCM.
M4

remote- B 1.7.0 Copy remote resources to the output directory for inclusion in the
resources artifact.

scm B 1.11.2 Execute SCM commands for the current project.

 scm-publish B 3.1.0 Publish your Maven website to a scm location.

scripting B 3.0.0 The Maven Scripting Plugin wraps the Scripting API according to
JSR223.

stage B 1.0 Assists with release staging and promotion.

toolchains B 3.0.0 Allows to share configuration across plugins.

wrapper B 3.0.2 Download and unpack the maven wrapper distribution (works only with
Maven 4)

Outside The Maven Land

At MojoHaus (formerly known as codehaus.org)
There are also many plug-ins available at the MojoHaus project at GitHub.
Here are a few common ones:

Plugin (see complete Description
list with version)

animal-sniffer Build signatures of APIs (JDK for example) and checks your classes against them.

build-helper Attach extra artifacts and source folders to build.

castor Generate sources from an XSD using Castor.

clirr Compare binaries or sources for compatibility using Clirr

javacc Generate sources from a JavaCC grammar.

 jdepend Generate a report on code metrics using JDepend.

nar-maven-plugin Compiles C, C++, Fortran for different architectures.

native Compiles C and C++ code with native compilers.

sql Executes SQL scripts from files or inline.

taglist Generate a list of tasks based on tags in your code.

versions Manage versions of your project, its modules, dependencies and plugins.

Misc
A number of other projects provide their own Maven plugins. This includes:

Plugin Maintainer Description

cargo Cargo Project Start/stop/configure J2EE containers and deploy to them.

clover Atlassian Generate a Clover report.

Clover

jetty Jetty Project Jetty Run a Jetty container for rapid webapp development.

jalopy Triemax Use Jalopy to format your source code.

rat Apache Release Audit Tool (RAT) to verify files.

Creadur
Project
Genesis Apache Verify legal files in artifacts.
Plugins Geronimo
Project

Apache Apache Run an Apache Tomcat container for rapid webapp development.
Tomcat Tomcat
Project

OWASP OWASP Run OWASP Dependency-Check, a utility that identifies project dependencie
dependency Dependency- publicly disclosed, vulnerabilities.
check Project
-check

CycloneDX CycloneDX Generate Software Bill of Materials (SBOM) in CycloneDX format.

Project

pgpverify Simplify4U Verify PGP signature of all project dependencies.

buildplan JC Gay Inspect the lifecycle of your build.

Maven Archetypes
https://maven.apache.org/guides/mini/guide-creating-archetypes.html
Introduction to Archetypes
What is Archetype?
In short, Archetype is a Maven project templating toolkit. An archetype is defined as an original
pattern or model from which all other things of the same kind are made. The name fits as we are
trying to provide a system that provides a consistent means of generating Maven projects.
Archetype will help authors create Maven project templates for users, and provides users with
the means to generate parameterized versions of those project templates.
Using archetypes provides a great way to enable developers quickly in a way consistent with
best practices employed by your project or organization. Within the Maven project, we use
archetypes to try and get our users up and running as quickly as possible by providing a sample
project that demonstrates many of the features of Maven, while introducing new users to the
best practices employed by Maven. In a matter of seconds, a new user can have a working
Maven project to use as a jumping board for investigating more of the features in Maven. We
have also tried to make the Archetype mechanism additive, and by that we mean allowing
portions of a project to be captured in an archetype so that pieces or aspects of a project can be
added to existing projects. A good example of this is the Maven site archetype. If, for example,
you have used the quick start archetype to generate a working project, you can then quickly
create a site for that project by using the site archetype within that existing project. You can do
anything like this with archetypes.
You may want to standardize J2EE development within your organization, so you may want to
provide archetypes for EJBs, or WARs, or for your web services. Once these archetypes are
created and deployed in your organization's repository, they are available for use by all
developers within your organization.
Using an Archetype

To create a new project based on an Archetype, you need to call  mvn

archetype:generate  goal, like the following:

1. mvn archetype:generate

Provided Archetypes
Maven provides several Archetype artifacts:

Archetype ArtifactIds Description

 maven-archetype- An archetype to generate a sample archetype project.
archetype

maven-archetype-j2ee- An archetype to generate a simplifed sample J2EE application.

simple

maven-archetype-mojo An archetype to generate a sample a sample Maven plugin.

maven-archetype-plugin An archetype to generate a sample Maven plugin.

maven-archetype- An archetype to generate a sample Maven plugin site.

plugin-site

maven-archetype- An archetype to generate a sample JSR-268 Portlet.

portlet

maven-archetype- An archetype to generate a sample Maven project.

quickstart

maven-archetype- An archetype to generate a simple Maven project.

simple

maven-archetype-site An archetype to generate a sample Maven site which demonstrates some of the sup
and FML and demonstrates how to i18n your site.

maven-archetype-site- An archetype to generate a sample Maven site.

simple

maven-archetype- An archetype to generate a sample Maven Webapp project.

webapp

For more information on these archetypes, please refer to the Maven Archetype Bundles page.
What makes up an Archetype?
Archetypes are packaged up in a JAR and they consist of the archetype metadata which
describes the contents of archetype, and a set of Velocity templates which make up the
prototype project. If you would like to know how to make your own archetypes, please refer to
our Guide to creating archetypes.

Guide to Creating Archetypes

Creating an archetype is a pretty straight forward process. An archetype is a very simple
artifact, that contains the project prototype you wish to create. An archetype is made up of:

 an archetype descriptor ( archetype-metadata.xml  in

directory:  src/main/resources/META-INF/maven/ ). It lists all the files that will be
contained in the archetype and categorizes them so they can be processed correctly
by the archetype generation mechanism.
 the prototype files that are copied by the archetype plugin
(directory:  src/main/resources/archetype-resources/ )
 the prototype pom ( pom.xml  in:  src/main/resources/archetype-resources )
 a pom for the archetype ( pom.xml  in the archetype's root directory).

To create an archetype follow these steps:

1. Create a new project and pom.xml for the archetype artifact

An example  pom.xml  for an archetype artifact looks as follows:

1. <project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

2. xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">

3. <modelVersion>4.0.0</modelVersion>

4.  

5. <groupId>my.groupId</groupId>

6. <artifactId>my-archetype-id</artifactId>

7. <version>1.0-SNAPSHOT</version>

8. <packaging>maven-archetype</packaging>
 9.  

10. <build>

11. <extensions>

12. <extension>

13. <groupId>org.apache.maven.archetype</groupId>

14. <artifactId>archetype-packaging</artifactId>

15. <version>3.1.1</version>

16. </extension>

17. </extensions>

18. </build>

19. </project>

All you need to specify is a  groupId ,  artifactId  and  version . These three parameters will be
needed later for invoking the archetype via  archetype:generate  from the commandline.

2. Create the archetype descriptor

The archetype descriptor is a file called  archetype-metadata.xml  which must be located in

the  src/main/resources/META-INF/maven/  directory. An example of an archetype descriptor
can be found in the quickstart archetype:

1. <archetype-descriptor

2. xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-
descriptor/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

3. xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-
plugin/archetype-descriptor/1.1.0 https://maven.apache.org/xsd/archetype-
descriptor-1.1.0.xsd"

4. name="quickstart">

5. <fileSets>
 6. <fileSet filtered="true" packaged="true">

7. <directory>src/main/java</directory>

8. </fileSet>

9. <fileSet>

10. <directory>src/test/java</directory>

11. </fileSet>

12. </fileSets>

13. </archetype-descriptor>

The attribute  name  tag should be the same as the  artifactId  in the archetype  pom.xml .

The boolean attribute  partial  show if this archetype is representing a full Maven project or only
parts.

The  requiredProperties ,  fileSets  and  modules  tags represent the differents parts of the
project:

 <requiredProperties>  : List of required properties to generate a project from this

archetype
 <fileSets>  : File sets definition
 <modules>  : Modules definition

At this point one can only specify individual files to be created but not empty directories.
Thus the quickstart archetype shown above defines the following directory structure:

archetype

|-- pom.xml

`-- src

`-- main

`-- resources

|-- META-INF

| `-- maven

| `--archetype-metadata.xml
 `-- archetype-resources

|-- pom.xml

`-- src

|-- main

| `-- java

| `-- App.java

`-- test

`-- java

`-- AppTest.java
3. Create the prototype files and the prototype pom.xml

The next component of the archetype to be created is the prototype  pom.xml .

Any  pom.xml  will do, just don't forget to the set  artifactId  and  groupId  as variables (  $
{artifactId}  /  ${groupId}  ). Both variables will be initialized from the commandline when
calling  archetype:generate .

An example for a prototype  pom.xml  is:

1. <project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

2. xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">

3. <modelVersion>4.0.0</modelVersion>

4.  

5. <groupId>${groupId}</groupId>

6. <artifactId>${artifactId}</artifactId>

7. <version>${version}</version>

8. <packaging>jar</packaging>

9.  

10. <name>${artifactId}</name>
 11. <url>http://www.myorganization.org</url>

12.  

13. <dependencies>

14. <dependency>

15. <groupId>junit</groupId>

16. <artifactId>junit</artifactId>

17. <version>4.12</version>

18. <scope>test</scope>

19. </dependency>

20. </dependencies>

21. </project>

4. Install the archetype and run the archetype plugin

Now you are ready to install the archetype:

1. mvn install

Now that you have created an archetype, you can try it on your local system by using the
following command. In this command, you need to specify the full information about the
archetype you want to use (its  groupId , its  artifactId , its  version ) and the information about
the new project you want to create ( artifactId  and  groupId ). Don't forget to include the version
of your archetype (if you don't include the version, you archetype creation may fail with a
message that version:RELEASE was not found)

1. mvn archetype:generate \

2. -DarchetypeGroupId=<archetype-groupId> \

3. -DarchetypeArtifactId=<archetype-artifactId> \

4. -DarchetypeVersion=<archetype-version> \

5. -DgroupId=<my.groupid> \
 6. -DartifactId=<my-artifactId>

Once you are happy with the state of your archetype, you can deploy (or submit it to Maven
Central) it as any other artifact and the archetype will then be available to any user of Maven.
Alternative way to start creating your Archetype
Instead of manually creating the directory structure needed for an archetype, simply use

1. mvn archetype:generate

2. -DgroupId=[your project's group id]

3. -DartifactId=[your project's artifact id]

4. -DarchetypeGroupId=org.apache.maven.archetypes

5. -DarchetypeArtifactId=maven-archetype-archetype

Afterwhich, you can now customize the contents of the  archetype-resources  directory,
and  archetype-metadata.xml , then, proceed to Step#4 (Install the archetype and run the
archetype plugin).
Project Object Model (POM)
https://www.tutorialspoint.com/maven/maven_pom.htm
POM stands for Project Object Model. It is fundamental unit of work in Maven. It is an XML file
that resides in the base directory of the project as pom.xml.
The POM contains information about the project and various configuration detail used by
Maven to build the project(s).
POM also contains the goals and plugins. While executing a task or goal, Maven looks for the
POM in the current directory. It reads the POM, gets the needed configuration information, and
then executes the goal. Some of the configuration that can be specified in the POM are
following −

 project dependencies
 plugins
 goals
 build profiles
 project version
 developers
 mailing list
Before creating a POM, we should first decide the project group (groupId), its name (artifactId)
and its version as these attributes help in uniquely identifying the project in repository.
POM Example

<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>com.companyname.project-group</groupId>
 <artifactId>project</artifactId>
<version>1.0</version>
</project>
It should be noted that there should be a single POM file for each project.
 All POM files require the project element and three mandatory fields: groupId,
artifactId, version.
 Projects notation in repository is groupId:artifactId:version.
 Minimal requirements for a POM −

Sr.No Node & Description

.

1
Project root
This is project root tag. You need to specify the basic schema settings such as
apache schema and w3.org specification.

2
Model version
Model version should be 4.0.0.

3
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.

4
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.

5
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.

Super POM
The Super POM is Maven’s default POM. All POMs inherit from a parent or default (despite
explicitly defined or not). This base POM is known as the Super POM, and contains values
inherited by default.
Maven use the effective POM (configuration from super pom plus project configuration) to
execute relevant goal. It helps developers to specify minimum configuration detail in his/her
pom.xml. Although configurations can be overridden easily.
An easy way to look at the default configurations of the super POM is by running the following
command: mvn help:effective-pom

https://maven.apache.org/guides/introduction/introduction-to-the-pom.html

What is a POM?
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that
contains information about the project and configuration details used by Maven to build the
project. It contains default values for most projects. Examples for this is the build directory,
which is  target ; the source directory, which is  src/main/java ; the test source directory, which
is  src/test/java ; and so on. When executing a task or goal, Maven looks for the POM in the
current directory. It reads the POM, gets the needed configuration information, then executes
the goal.
Some of the configuration that can be specified in the POM are the project dependencies, the
plugins or goals that can be executed, the build profiles, and so on. Other information such as
the project version, description, developers, mailing lists and such can also be specified.
Super POM
The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set,
meaning the configuration specified in the Super POM is inherited by the POMs you created for
your projects.
You can see the Super POM for Maven 3.6.3 in Maven Core reference documentation.
Minimal POM
The minimum requirement for a POM are the following:

 project  root
 modelVersion  - should be set to 4.0.0
 groupId  - the id of the project's group.
 artifactId  - the id of the artifact (project)
 version  - the version of the artifact under the specified group

Here's an example:
 1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-app</artifactId>

6. <version>1</version>

7. </project>

A POM requires that its groupId, artifactId, and version be configured. These three values form
the project's fully qualified artifact name. This is in the form of <groupId>:<artifactId>:<version>.
As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".
Also, as mentioned in the first section, if the configuration details are not specified, Maven will
use their defaults. One of these default values is the packaging type. Every Maven project has a
packaging type. If it is not specified in the POM, then the default value "jar" would be used.
Furthermore, you can see that in the minimal POM the repositories were not specified. If you
build your project using the minimal POM, it would inherit the repositories configuration in the
Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know
that these dependencies will be downloaded
from  https://repo.maven.apache.org/maven2  which was specified in the Super POM.

Project Inheritance
Elements in the POM that are merged are the following:

 dependencies
 developers and contributors
 plugin lists (including reports)
 plugin executions with matching ids
 plugin configuration
 resources

The Super POM is one example of project inheritance, however you can also introduce your
own parent POMs by specifying the parent element in the POM, as demonstrated in the
following examples.
Example 1
The Scenario
As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us
introduce another artifact, com.mycompany.app:my-module:1.
 1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-module</artifactId>

6. <version>1</version>

7. </project>

And let us specify their directory structure as the following:

|-- my-module

| `-- pom.xml

`-- pom.xml

Note:  my-module/pom.xml  is the POM of com.mycompany.app:my-module:1

while  pom.xml  is the POM of com.mycompany.app:my-app:1

The Solution
Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact of
com.mycompany.app:my-module:1,we will have to modify com.mycompany.app:my-module:1's
POM to the following configuration:
com.mycompany.app:my-module:1's POM

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <parent>

5. <groupId>com.mycompany.app</groupId>

6. <artifactId>my-app</artifactId>
 7. <version>1</version>

8. </parent>

9.  

10. <groupId>com.mycompany.app</groupId>

11. <artifactId>my-module</artifactId>

12. <version>1</version>

13. </project>

Notice that we now have an added section, the parent section. This section allows us to specify
which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact
name of the parent POM. With this setup, our module can now inherit some of the properties of
our parent POM.
Alternatively, if you want the groupId or the version of your modules to be the same as their
parents, you can remove the groupId or the version identity of your module in its POM.

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <parent>

5. <groupId>com.mycompany.app</groupId>

6. <artifactId>my-app</artifactId>

7. <version>1</version>

8. </parent>

9.  

10. <artifactId>my-module</artifactId>

11. </project>

This allows the module to inherit the groupId or the version of its parent POM.
Example 2
The Scenario
However, that would work if the parent project was already installed in our local repository or
was in that specific directory structure (parent  pom.xml  is one directory higher than that of the
module's  pom.xml ).

But what if the parent is not yet installed and if the directory structure is as in the following
example?

|-- my-module

| `-- pom.xml

`-- parent

`-- pom.xml
The Solution
To address this directory structure (or any other directory structure), we would have to add
the  <relativePath>  element to our parent section.

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <parent>

5. <groupId>com.mycompany.app</groupId>

6. <artifactId>my-app</artifactId>

7. <version>1</version>

8. <relativePath>../parent/pom.xml</relativePath>

9. </parent>

10.  

11. <artifactId>my-module</artifactId>
 12. </project>

As the name suggests, it's the relative path from the module's  pom.xml  to the
parent's  pom.xml .

Project Aggregation
Project Aggregation is similar to Project Inheritance. But instead of specifying the parent POM
from the module, it specifies the modules from the parent POM. By doing so, the parent project
now knows its modules, and if a Maven command is invoked against the parent project, that
Maven command will then be executed to the parent's modules as well. To do Project
Aggregation, you must do the following:

 Change the parent POMs packaging to the value "pom".

 Specify in the parent POM the directories of its modules (children POMs).

Example 3
The Scenario
Given the previous original artifact POMs and directory structure:
com.mycompany.app:my-app:1's POM

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-app</artifactId>

6. <version>1</version>

7. </project>

com.mycompany.app:my-module:1's POM

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  
 4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-module</artifactId>

6. <version>1</version>

7. </project>

directory structure

|-- my-module

| `-- pom.xml

`-- pom.xml
The Solution
If we are to aggregate my-module into my-app, we would only have to modify my-app.

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-app</artifactId>

6. <version>1</version>

7. <packaging>pom</packaging>

8.  

9. <modules>

10. <module>my-module</module>

11. </modules>

12. </project>
In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections
were added. For the packaging, its value was set to "pom", and for the modules section, we
have the element  <module>my-module</module> . The value of  <module>  is the relative path
from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (by
practice, we use the module's artifactId as the module directory's name).
Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same
Maven command would be ran against com.mycompany.app:my-module:1 as well.
Furthermore, some commands (goals specifically) handle project aggregation differently.
Example 4
The Scenario
But what if we change the directory structure to the following:

|-- my-module

| `-- pom.xml

`-- parent

`-- pom.xml
How would the parent POM specify its modules?
The Solution
The answer? - the same way as Example 3, by specifying the path to the module.

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-app</artifactId>

6. <version>1</version>

7. <packaging>pom</packaging>

8.  

9. <modules>

10. <module>../my-module</module>
 11. </modules>

12. </project>

Project Inheritance vs Project Aggregation

If you have several Maven projects, and they all have similar configurations, you can refactor
your projects by pulling out those similar configurations and making a parent project. Thus, all
you have to do is to let your Maven projects inherit that parent project, and those configurations
would then be applied to all of them.
And if you have a group of projects that are built or processed together, you can create a parent
project and have that parent project declare those projects as its modules. By doing so, you'd
only have to build the parent and the rest will follow.
But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you
can have your modules specify a parent project, and at the same time, have that parent project
specify those Maven projects as its modules. You'd just have to apply all three rules:

 Specify in every child POM who their parent POM is.

 Change the parent POMs packaging to the value "pom" .
 Specify in the parent POM the directories of its modules (children POMs)

Example 5
The Scenario
Given the previous original artifact POMs again,
com.mycompany.app:my-app:1's POM

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-app</artifactId>

6. <version>1</version>

7. </project>

com.mycompany.app:my-module:1's POM

1. <project>
 2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-module</artifactId>

6. <version>1</version>

7. </project>

and this directory structure

|-- my-module

| `-- pom.xml

`-- parent

`-- pom.xml
The Solution
To do both project inheritance and aggregation, you only have to apply all three rules.
com.mycompany.app:my-app:1's POM

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <groupId>com.mycompany.app</groupId>

5. <artifactId>my-app</artifactId>

6. <version>1</version>

7. <packaging>pom</packaging>

8.  

9. <modules>
 10. <module>../my-module</module>

11. </modules>

12. </project>

com.mycompany.app:my-module:1's POM

1. <project>

2. <modelVersion>4.0.0</modelVersion>

3.  

4. <parent>

5. <groupId>com.mycompany.app</groupId>

6. <artifactId>my-app</artifactId>

7. <version>1</version>

8. <relativePath>../parent/pom.xml</relativePath>

9. </parent>

10.  

11. <artifactId>my-module</artifactId>

12. </project>

NOTE: Profile inheritance the same inheritance strategy as used for the POM itself.
Project Interpolation and Variables
One of the practices that Maven encourages is don't repeat yourself. However, there are
circumstances where you will need to use the same value in several different locations. To
assist in ensuring the value is only specified once, Maven allows you to use both your own and
pre-defined variables in the POM.

For example, to access the  project.version  variable, you would reference it like so:

1. <version>${project.version}</version>
One factor to note is that these variables are processed after inheritance as outlined above.
This means that if a parent project uses a variable, then its definition in the child, not the parent,
will be the one eventually used.
Available Variables
Project Model Variables
Any field of the model that is a single value element can be referenced as a variable. For
example,  ${project.groupId} ,  ${project.version} ,  ${project.build.sourceDirectory}  and so on.
Refer to the POM reference to see a full list of properties.

These variables are all referenced by the prefix " project. ". You may also see references
with  pom.  as the prefix, or the prefix omitted entirely - these forms are now deprecated and
should not be used.
Special Variables

project.basedir The directory that the current project resides in.

project.baseUri The directory that the current project resides in, represented as an URI. Sin

maven.build.timestamp The timestamp that denotes the start of the build (UTC). Since Maven 2.1.0

The format of the build timestamp can be customized by declaring the

property  maven.build.timestamp.format  as shown in the example below:

1. <project>

2. ...

3. <properties>

4. <maven.build.timestamp.format>yyyy-MM-
dd'T'HH:mm:ss'Z'</maven.build.timestamp.format>

5. </properties>

6. ...

7. </project>
The format pattern has to comply with the rules given in the API documentation
for SimpleDateFormat. If the property is not present, the format defaults to the value already
given in the example.
Properties
You are also able to reference any properties defined in the project as a variable. Consider the
following example:

1. <project>

2. ...

3. <properties>

4. <mavenVersion>3.0</mavenVersion>

5. </properties>

6.  

7. <dependencies>

8. <dependency>

9. <groupId>org.apache.maven</groupId>

10. <artifactId>maven-artifact</artifactId>

11. <version>${mavenVersion}</version>

12. </dependency>

13. <dependency>

14. <groupId>org.apache.maven</groupId>

15. <artifactId>maven-core</artifactId>

16. <version>${mavenVersion}</version>

17. </dependency>

18. </dependencies>
 19. ...

20. </project>

Source Control Integration

https://www.tutorialspoint.com/maven/maven_repositories.htm

What is a Maven Repository?

In Maven terminology, a repository is a directory where all the project jars, library jar, plugins or
any other project specific artifacts are stored and can be used by Maven easily.
Maven repository are of three types. The following illustration will give an idea regarding these
three types.

 local
 central
 remote

Local Repository
Maven local repository is a folder location on your machine. It gets created when you run any
maven command for the first time.
Maven local repository keeps your project's all dependencies (library jars, plugin jars etc.).
When you run a Maven build, then Maven automatically downloads all the dependency jars
into the local repository. It helps to avoid references to dependencies stored on remote
machine every time a project is build.
Maven local repository by default get created by Maven in %USER_HOME% directory. To
override the default location, mention another path in Maven settings.xml file available at
%M2_HOME%\conf directory.

<settings xmlns = "http://maven.apache.org/SETTINGS/1.0.0"

xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>C:/MyLocalRepository</localRepository>
</settings>
When you run Maven command, Maven will download dependencies to your custom path.
Central Repository
Maven central repository is repository provided by Maven community. It contains a large
number of commonly used libraries.
When Maven does not find any dependency in local repository, it starts searching in central
repository using following URL − https://repo1.maven.org/maven2/
Key concepts of Central repository are as follows −

 This repository is managed by Maven community.

 It is not required to be configured.
 It requires internet access to be searched.
To browse the content of central maven repository, maven community has provided a URL
− https://search.maven.org/#browse. Using this library, a developer can search all the available
libraries in central repository.
Remote Repository
Sometimes, Maven does not find a mentioned dependency in central repository as well. It then
stops the build process and output error message to console. To prevent such situation, Maven
provides concept of Remote Repository, which is developer's own custom repository
containing required libraries or other project jars.
For example, using below mentioned POM.xml, Maven will download dependency (not
available in central repository) from Remote Repositories mentioned in the same pom.xml.

<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>com.companyname.projectgroup</groupId>
<artifactId>project</artifactId>
<version>1.0</version>
 <dependencies>
<dependency>
<groupId>com.companyname.common-lib</groupId>
<artifactId>common-lib</artifactId>
<version>1.0.0</version>
</dependency>
<dependencies>
<repositories>
<repository>
<id>companyname.lib1</id>
<url>http://download.companyname.org/maven2/lib1</url>
</repository>
<repository>
<id>companyname.lib2</id>
<url>http://download.companyname.org/maven2/lib2</url>
</repository>
</repositories>
</project>
Maven Dependency Search Sequence
When we execute Maven build commands, Maven starts looking for dependency libraries in
the following sequence −
 Step 1 − Search dependency in local repository, if not found, move to step 2 else
perform the further processing.
 Step 2 − Search dependency in central repository, if not found and remote
repository/repositories is/are mentioned then move to step 4. Else it is downloaded to
local repository for future reference.
 Step 3 − If a remote repository has not been mentioned, Maven simply stops the
processing and throws error (Unable to find dependency).
 Step 4 − Search dependency in remote repository or repositories, if found then it is
downloaded to local repository for future reference. Otherwise, Maven stops processing
and throws error (Unable to find dependency).

https://maven.apache.org/archives/maven-1.x/using/scm.html

Working with Source Control

Working with your source control system in Maven is quite simple. Maven can provide the
following services:

 Common tasks such as checking out code, tagging the current code, and performing an
update
 Generating reports on the recent usage history of source control
  Providing links to a web view of the source control, and if desired publishing that
information to the project site

Support is provided by the Maven SCM subproject. This provides support for the following
SCM systems:

 CVS
 Subversion
 ClearCase (partial)
 Perforce (partial)
 StarTeam (partial)
 Visual SourceSafe (planned)

Configuration is extremely simple - in most cases, you need only specify

the <connection/> string in the <repository/> element of your POM. Specifics about this
connection string can be found in the SCM plugin documentation.

Performing Common Tasks

It is possible to perform several common tasks with Maven. These can be particularly useful
for automation in your development environment, or in continuous integration.

There are also goals that provide assistance with making releases from your SCM.

For more information about common tasks and SCM based releases, see the SCM Plugin
Documentation. This contains a complete guide to the scm: goals and related properties.

For general information on making releases with Maven, please see Making Releases.

Generating Reports

Maven provides three different reports on SCM usage that can be included in your project
site. These are provided by the Change Log, File Activity and Developer Activity plugins.

These are included in your project site by default, however if you would like to explicitly select
them for your project, add any or all of the following lines to project.xml inside
the <reports/> section:

<report>maven-changelog-plugin</report>
<report>maven-file-activity-plugin</report>
<report>maven-developer-activity-plugin</report>