Basics of Maven explained

1. Maven
Prepared By : Smita Prasad

2. Topics to be covered
• What is Maven and its setup
• POM
• Relationships
• Creating a project
• Execution Groups
• Mvn command
• Built-in Lifecycles
• Build Settings
• Dependency Management

3. Common Problems and Activities
• Multiple Jars
• Jar have Dependencies and versions
• Project Structure
• Building , Publishing and Deploying

4. What is Maven?
• Maven, is a Yiddish word meaning
“Accumulator Of Knowledge”
• It is a Plugin Execution Framework
• Used for software lifecycle management
• Provides a cohesive suite of plugins for
• verification,
• compilation,
• testing,
• packaging,
• reporting,
• and deployment.

5. Interoperability and Extensibility
• It offers easy-to-write custom build-
supplementing plugins
• Reuses any desired aspect of Ant
• Can compile native C, C++, and .NET code
• Strong support for Java and JVM languages
and platforms, such as Scala, JRuby, Groovy
and Grails.
• For PHP users there is a separate project by
Apache called PHP-Maven.

6. History
Maven began its life in the Jakarta Alexandria project.
The Alexandria project is now defunct.
It was only part of this for 5 months.

7. Ant v/s Maven

8. Installing Apache Maven
• Extract the archive and adding the bin folder with the mvn command to the PATH.
• Detailed steps are:
– Ensure JAVA_HOME environment variable is set and points to your JDK
installation
– Setup M2_HOME to a directory under the windows user directory with a folder
called .m2
– Extract distribution archive in any directory
– unzip apache-maven-3.3.3-bin.zip
– Add the bin directory of the created directory apache-maven-3.3.3 to
the PATH environment variable
– Confirm with mvn -v in a new shell. The result should look similar to
set M2_HOME=c:maven-3.2.x-SNAPSHOT
set PATH=%M2_HOME%bin;%PATH%

9. POM
• POM stands for
"Project Object
Model“
• XML
representation
of a Maven
project held in a
file
named pom.xml

10. Artifact Vector
• Each Maven project produces an element, such as a
JAR, WAR or EAR, uniquely identified by a composite of
fields known as groupId, artifactId, packaging, version
and scope.
• This vector of fields uniquely distinguishes a Maven
artifact from all others.
• Many Maven reports and plugins print the details of a
specific artifact in this colon separated fashion:
groupid:artifactid:packaging:version:scope
• An example of this output for the core Spring JAR
would be:
org.springframework:spring:jar:2.5.6:compile

11. Maven Coordinates
• groupId: This is generally unique amongst an organization or a project. When stored within a
repository, the group acts much like the Java packaging structure does in an operating
system. The dots are replaced by OS specific directory separators (such as '/' in Unix) which
becomes a relative directory structure from the base repository.
– Example: The org.codehaus.mojo group lives within the
directory $M2_REPO/org/codehaus/mojo.
• artifactId: Name that the project is known by.
– Example: my-project lives in $M2_REPO/org/codehaus/mojo/my-project.
• packaging: Project’s artifact type. Default value is jar. The current core packaging values
are: pom, jar, maven-plugin, ejb, war, ear, rar, par. These define the default list of goals which
execute to each corresponding build lifecycle stage for a particular package structure.
• version: Code changes, those changes should be versioned, and this element keeps those
versions in line. It is also used within an artifact's repository to separate versions from each
other.
– Example: my-project version 1.0 files live in the directory
structure $M2_REPO/org/codehaus/mojo/my-project/1.0.

12. POM Relationships
• Super POM
• Inheritance
• Aggregation
• Properties
• Dependencies

13. Super POM
Super
POM
POM1 POM2 POM3
• The Super POM is Maven's default POM.
• It is Pseudo-invisible.
• All projects inherit it.
• Specifies file location defaults.
• Locks version of common plugins.

15. Project Inheritance
<project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-module</artifactId>
<version>1</version>
</project>
Parent tags in the module pom

16. Providing a uniform build system
Project 1
Project 5
Project 2
Project 3
Project 4
POM & Plugins
MAVEN

17. Project Aggregation
• Instead of specifying the parent POM from the module, it specifies the
modules from the parent POM
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
<packaging>pom</packaging>
<modules>
<module>my-module</module>
</modules>
</project>

18. Inheritance Aggregation
When several Maven projects have similar
configurations -- refactor your projects by
pulling out those similar configurations
and making a parent project.
When a group of projects that are built or
processed together -- Create a parent
project and have that parent project
declare those projects as its modules.
Let your Maven projects inherit that
parent project, and those configurations
would then be applied to all of them.
Just build the parent and the rest will
follow.
You can have both Project Inheritance and Project Aggregation at the same time.
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)

19. Properties
• One of the practices that Maven encourages is don't repeat
yourself.
• Maven allows you to use both your own and pre-defined variables
in the POM.
They come in 5 different styles—
1) ${ env.X}  ${ env.PATH}
2) ${ java.X}  ${ java.HOME}
3) ${ project.X}  ${ project.version}
4) ${ system.X}  ${ system.offline}
5) ${X}  ${ someVar}

20. Creating a Project via Archetype
• $ mvn archetype:generate
• 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.
• You can choose from various templates available.
• You can also create your own archetype template.

22. Command to execute--
Directory Structure Created for the project my-app

23. Pom file generated via archetype

24. EXECUTION GROUPS
• Maven divides execution into four
nested hierarchies.
• From most-encompassing to most-
specific,
• They are:
Lifecycles, Phases, Plugins and Goals
• Lifecycle - Flow of steps
• Phase - A step in a lifecycle
• Plugin – Logical grouping and
distribution of related goals
• Goal - Single executable task

25. THE MVN COMMAND
• Maven supplies a Unix shell script and MSDOS
batch file named mvn and mvn.bat
respectively.
• This command is used to start all Maven
builds.
• Optional parameters are supplied in a space-
delimited fashion.
mvn clean package jetty:run –Dmaven.test.skip

26. Executing a Phase or Goal
• At the command prompt, either a phase or a plugin
goal can be requested.
• Multiple phases or goals can be specified and are
separated by spaces.
• Example -
mvn compile:compile jar:jar
• If you execute a phase, all phases and bound plugin
goals up to that point in the lifecycle are also executed.
• Example -
mvn deploy
This example requests the deploy
lifecycle phase, which will also execute
the verification, compilation, testing
and packaging phases.

27. Built-in Maven Lifecycles
• Maven ships with three lifecycles; clean,
default, and site.
• The clean lifecycle is simplistic in nature. It
deletes all generated and compiled artifacts in
the output directory.

28. • The default lifecycle defines the most commonly used phases
for building an application, ranging from compilation of the
code to installation of the completed artifacts, such as a JAR,
into a remote Maven repository.

30. • The site lifecycle generates a project information
web site, and can deploy the artifacts to a specified
web server or local path.

31. Build Settings
• defaultGoal: the default goal or phase to execute if none is
given.
• directory: This is the directory where the build will dump its
files.
• finalName: This is the name of the bundled project when it is
finally built.It defaults to ${artifactId}-${version}.
• filter: Defines *.properties files that contain a list of
properties that apply to resources on build.

32. Resources
• Specify where the resource files will be placed in the artifact.

33. Add Resources to JAR
Just place the files in the “resources
” folder
It is added in JAR under META-INF
folder

34. Filter Resources
• A resource file may need to contain a value that
can only be supplied at build time.
• To accomplish this in Maven, put a reference to
the property that will contain the value into your
resource file using the syntax
– ${<property name>}
• The property can be one of the values defined in
– your pom.xml,
– a value defined in the user's settings.xml,
– a property defined in an external properties file,
– or a system property.

35. Enable Filtering
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>

36. Filtering Examples

37. Using External Properties File
application.name=${pom.name}
application.version=${pom.version}
message=${my.filter.value}
In application.properties
my.filter.value=hello!
In filter.properties
In pom.xml

38. DEPENDENCIES
• To express your project’s reliance on a particular artifact,
you declare a dependency in the project’s pom.xml.

39. Transitive Dependency

40. Transitive Dependencies Discovery
Feature Description
Dependency mediation Determines what version of a dependency is to be used when
multiple versions of an artifact are encountered. If two
dependency versions are at the same depth in the dependency
tree, the first declared dependency will be used.
Dependency management Directly specify the versions of artifacts to be used when they are
encountered in transitive dependencies. For an example project C
can include B as a dependency in its dependencyManagement
section and directly control which version of B is to be used when
it is ever referenced.
Dependency scope Includes dependencies as per the current stage of the build
Excluded dependencies Any transitive dependency can be excluede using "exclusion"
element. As example, A depends upon B and B depends upon C
then A can mark C as excluded.
Optional dependencies Any transitive dependency can be marked as optional using
"optional" element. As example, A depends upon B and B
depends upon C. Now B marked C as optional. Then A will not use
C.

41. DependencyManagement

42. • Used to pull all the dependency information
into a common POM file, simplifying the
references in the child POM file.
• Used when you have multiple attributes that
you don’t want to retype in under multiple
children projects.
• Used to define a standard version of an
artifact to use across multiple projects.

43. VISUALIZE Dependencies
• List view
‣ mvn dependency:resolve
• Tree view
‣ mvn dependency:tree
• Plugin list view
‣ mvn dependency:resolve-plugins

44. Standard Scopes
• Each dependency can specify a scope, which controls its visibility
and inclusion in the final packaged artifact, such as a WAR or EAR.
• Scoping enables you to minimize the JARs that ship with your
product.

45. Exclusion

46. Thanks