Saturday, April 2, 2016

Maven Fundamentals

1.0 High Level Overview

·         Open Source product
·         Managed by the Apache Software Foundation
·         Build tool
o   Always produces one artifact or component
o   Helps manage dependencies
·         Project management tool
o   Handles versioning and releases of your code
o   Meta info: Describes what the project is doing or what it produces
o   Easily produce JavaDocs
o   Produce other site information
·         Maven sites are built with Maven. All the Layout is made with Maven’s site generation features.

2.0 Why use Maven

·         Repeatable builds
·         Recreate a build for any environment
·         Transitive dependencies
o   Downloading dependencies also pulls other items needed
·         Contains everything you need build your code
·         Works with a local repo
o   Local repo keeps the dependencies in a local repo
o   If local repo already contains the dependency required for a particular project, Maven just references the dependency binary stored in the repo.
o   If local repo does not contain the dependency required for a project, Maven downloads the dependency from public or privately hosted maven repo to the local repo.
·         Works with IDS and also as a standalone
·         Preferred choice with build tools like Jenkins

3.0 Ant Vs Maven

3.0.1 Ant

·         Ant was developed to replace a build tool called make, which was not a cross platform tool. Make was brittle and limited to unix.
·         Ant is built on top of Java and uses XML
·         Ant is very procedural
o   It is hard to inherit anything
o   You have to go out of your way to use different pieces and have it stretched out to be able to use composition inside the ant scripts.
·         Ant isn’t a build tool
·         You have to explicitly do everything in Ant
·         Everything needs to be defined. It is very declarative.
·         No standard out there.
·         Nothing can get carried over from one project to another.
·         Each organization, team and individual can define keywords like clean, init etc. and each one could have a different meaning. Nothing is implicit.
·         No possibility of reuse. You’d have to copy over the entire ant script from one project to another if you want to reuse. Ant build.xml

3.0.2 Maven

·         Maven is a proper build tool
·         mvn clean – is always maven clean
·         Inheritance in projects is implicitly available
·         Transitive dependencies
·         Consistent across projects
·         Functionality and keywords are strongly defined and standardization is implicit.
·         In built versioning features – snapshot vs release
·         Maven follows a convention over configuration model
·         Maven is centered around managing your entire project’s lifecycle Pros and Cons Maven pom.xml

4.0 Installation Best Practices

4.0.1 Environment variables

System variables
JAVA_HOME – c:\Program Files\Java\jdk1.8.0_73
MAVEN_HOME – c:\work\tools\build\apache-maven-3.3.3
Add JAVA_HOME and MAVEN_HOME to the Path - %JAVA_HOME%/bin; %MAVEN_HOME%/bin;

5.0 Demo: Hello World

1.       Create a new project named HelloWorld in the IDE of your choice.

2.       Create a file named pom.xml and add the following xml.
       <!-- Associate group Id with your site or organization name. -->
       <!--  name of our application -->
       <!-- Version of the XML schema structure used in the project. -->
3.       Create source folder structure in the HelloWorld project - src/main/java
4.       Create a file in src/main/java and add the following code.
public HelloWorld {
              public static void main (String args[]) {
                     System.out.println("Hello World");

5.       In command prompt or shell, change directory to the project folder and execute the following commands.

mvn clean
mvn compile

This will generate a target directory with classes directory where HelloWorld.class will be stored.

mvn package

This will generate a HelloWorld-1.0-SNAPSHOT.jar file in the target directory.

6.0 Folder structure

1.       Maven looks for src/main/java by default.
a.       All Java code of our package is stored here.
b.      This is the beginning of our package declaration. Example: com.iaditya.helloworld package structure exists in src/main/java/com/iaditya/helloworld.
c.       Other languages: src/main/groovy

2.       Unit test cases are stored in src/test/java.

3.       Maven compiles all code to a target directory by referencing defaults and anything we have overridden in the pom.xml file.
a.       All unit tests get run from the target folder.
b.      Contents from this directory get packaged into jar, war or ear file.

7.0 POM file basics

7.0.1 Parts of a POM file

POM files can be classified into 4 basic parts.
1.       Project Information
a.       groupId – Often it is the package in our code.
b.      artifactId – Name of our application.
c.       version – Current version. Snapshot vs Release.
d.      packaging – How do we want to package our application? ear, war, jar or other package types.
2.       Dependencies –
a.       Actual artifacts we want to use in our application.
3.       Build
a.       Plugins – The plugins we want to use to build our code?
b.      Directory structure
                                                               i.      To override the src/main/java directory
                                                             ii.      Target name
                                                            iii.      Location of target
                                                           iv.      Location of specific resources, generated sources and xml etc.
4.       Repositories
a.       Download artifacts from repositories
b.      Optionally download from maven central
c.       Download from private maven repo hosted in your organization

7.0.2 Dependencies Intro

Often considered the most confusing part of Maven.
1.       Dependencies are imported by their naming convention.
2.       We have to know the following three of any dependency you are looking to use in your code.
a.       groupId
b.      artifactId
c.       version
3.       Added to the dependencies section in the pom.xml.
a.       List the dependency that we want to use
b.      Transitive dependencies will be pulled by Maven
       <!-- Associate group Id with your site or organization name. -->
       <!--  name of our application -->
       <!-- Version of the XML schema structure used in the project. -->

              <!-- Package -->
              <!-- Name of our application -->

7.0.3 Goals

1.       clean – deletes the target directory and any generated sources
2.       compile 
a.       Compiles the source code
b.      Generates any files
c.       Copies resources to our classes directory
3.       package
a.       Runs compile first
b.      Runs unit tests
c.       Packages the app based on the packaging type defined in pom.xml
4.       install
a.       Runs the package command and installs it in your local repo
5.       deploy
a.       Runs the install command and deploys it to a private repository.
b.      Does not deploy to an app server.

7.0.4 Running maven goals

Maven goals can be run individually.
mvn clean
mvn compile
mvn package
mvn install
mvn deploy

And they can be daisy-chained.
mvn clean package

7.0.5 Local repo

1.       Maven stores everything it downloads to a local repository folder on the hard drive. Usually, it is installed in the home directory\.m2 folder.

2.       Avoids duplication. Otherwise, we would end up copying the dependency into every project and storing it in the SCM.

3.       Stores artifacts using the information provided in the pom.xml for the dependencies. Folders named artifactId, groupId and version are created.

7.0.6 Overriding defaults in the build section

Defaults that are implicitly followed by Maven can be overridden in the build section of the pom.xml. In the following example, we are overriding the target package name. By default, the target package name in our HelloWorld example will be HelloWorld-1.0-SNAPSHOT.jar.
              <!-- Associate group Id with your site or organization name. -->
              <!--  name of our application -->
              <!-- Version of the XML schema structure used in the project. -->
                     <!-- Package -->
                     <!-- Name of our application -->
              <!-- Override the target package name. -->

8.0 Maven Dependencies

1.       Dependencies are other resources that we want to use inside of our application.

2.       Maven will pull transitive dependencies based on the dependencies we list.

3.       Minimum required info to pull dependencies:
a.       groupId
b.      artifactId
c.       version

8.0.1 Versions

1.       Development starts off as a SNAPSHOT

2.       SNAPSHOT allows us to push new code to a repository and have our IDE or command line automatically check for changes every time.

3.       If we specify a SNAPSHOT version in our pom.xml, Maven will pull down new code every time it runs and uses the new code.

4.       SNAPSHOT keyword has to be all capital. It does not work as a SNAPSHOT otherwise.

5.       This SNAPSHOT functionality saves you from re-releasing versions for development.

6.       Never deploy to production with a SNAPSHOT because we cannot reproduce or re-create that code. The next time we compile the code, the functionality could be different in the code.

7.       A release does not have to have a specific naming convention. Example: HelloWorld-1.0.jar, HelloWorld-1.0.1.jar

8.       Milestone releases like HelloWorld-1.0-M1.jar or HelloWorld-1.0-RC1.jar do not effect Maven. Such milestone or release candidate versions are published for evaluation purposes and should not be considered as release versions.

9.       RELEASE versions are sometimes named with a keyword RELEASE, although it is not necessary.

8.0.2 Types

1.       Types refer to the type of resource that we want to include inside of our application.

2.       The default and the most common type is a jar.

3.       The current core packaging types are pom, jar, maven-plugin, ejb, war, ear, rar and par.

4.       The type of pom is referred to a dependency pom.
a.       All dependencies inside the pom are downloaded into our application.
b.      Commonly referred to as a dependency pom.
c.       Example: If you have web services in your organization and you want to group all of these dependencies that we use for a anytime we want to create a web service, like Jersey libraries and other different XML dependencies, all those dependencies can be put into one pom and reference that pom in your project and Maven will download that into our application.
5.       Types refer to packaging inside our application. If we are building an artifact for other people to consume, we need to specify our packaging in the pom.

8.0.3 Transitive dependencies

1.       The main reason people begin using maven.

2.       If we add a dependency like hibernate, it will go ahead and pull down any and all transitive dependencies that hibernate needs.

3.       If there is a conflict, Maven will resolve those by choosing the newer version.

8.0.4 Scopes

Six scopes available for dependencies:
1.       compile
a.       Default scope
b.      Resources or artifacts are available everywhere inside your application.
2.       provided
a.       Like compile
b.      Means the artifact is going to be available throughout your entire build cycle, but it’s not going to be added to the final artifact.
c.       Example: servlet-api, xml-apis
3.       runtime
a.       Not needed for compilation
b.      Needed for execution
c.       Included in the runtime and test classpaths, but not the compile classpaths.
d.      Example: Dynamically loaded libraries like jdbc jars
e.      Not bundled with our final artifact
4.       Test
a.       Available for the test compilation and execution phase only.
b.      Not included in the final artifact
5.       system
a.       It is recommended NOT to use system as it is very brittle and breaks the reason for wanting to use maven.
b.      It is used for hard coding a path to a jar on your file system.
6.       import
a.       Deals with dependency management
b.      Advanced topic.
c.       Review at

9.0 Repositories

1.       Repositories are http accessible locations where maven looks at to download code and other artifacts to use in our application.

2.       For internal repo, it is advisable to secure it as an https accessible location.

3.       The default location of the repo is stored in the super pom.xml, which is located inside the maven installation.

4.       This super pom.xml can be overridden using settings.xml or our project’s pom.xml.

5.       Default location is

6.       Multiple repositories are allowed.

7.       Corporate repository options:
a.       Nexus (recommended)
b.      Artifactory

9.0.1 Dependency Repo

1.       It is where we download all our dependencies from.

2.       It can contain releases or snapshots or both.

3.       It is common to have releases and snapshots in separate repositories.

4.       Sample repositories section in pom.xml.
                     <!-- User defined id -->
                     <!-- User defined desciption entered in the name tag -->
                     <name>Spring Maven SNAPSHOT Repository</name>
                     <!-- Repo url of the dependency artifact needed in your code -->

9.0.2 Plugin Repo

1.       Identical to dependency repositories, just deals with Plugins.

2.       Maven will only look for plugins in this repo as by design a plugins repo is usually a separate repository.

3.       Defined very similar to dependency repository.

4.       Snapshots and releases just like the dependency repository.

5.       Optionally, custom plugins can be created and stored in an internal or corporate repository.

9.0.3 Releases/Snapshots

1.       Snapshots and releases can come from the same repo, but usually organizations prefer to keep them separate.

2.       Most projects end up having a lot of snapshots, release candidates and milestone releases for each release. It is easier to maintain a separate repo for releases to make it easier to push truly releasable code to an app store or a customer access site.

10.0 Maven Plugins

Maven uses plugins to build and package our application beyond just downloading and storing artifacts locally.

10.0.1 Goals

1.       Goals like clean, compile etc. are plugins configured in the maven install.
2.       These goals are defined in the super pom which are added to your project’s effective pom.
3.       Goals are always tied to a phase.
4.       The default goal’s phases can be overridden in your project’s pom if required.

10.0.2 Phases

1.       validate – this validates that
a.       The project is correct
b.      It has all the plugins needed
c.       It has all the artifacts downloaded
d.      All structures are in place
e.      Has permissions to create directories.
2.       compile
a.       Our source code compilation happens.
b.      Testing code does not get compiled.
3.       test
a.       Testing code gets compiled.
b.      Testing of the compiled source code happens.
4.       package
a.       Packages all of our code in its defined packaging such as jar.
b.      It doesn’t do anything with it once it is packaged, but allows us to test to make sure that everything is in the proper order in which it should be.
c.       Usually, developers tie generating sources or JavaDoc to this phase.
5.       integration test
a.       Allows us to deploy and run integration tests
b.      New to maven 3. Not used by most yet.
6.       verify
a.       Runs checks against package to verify integrity before installing to our local repo or our private repo.
7.       install
a.       Install the package in our local repo
8.       deploy
a.       Copy final package to a remote or private repo

10.0.3 Compiler plugin

1.       The plugin used to compile the source code in our application.
2.       Used to compile both source code and test code using different phases.
3.       Invoke java by setting the classpath with the dependencies from our application.
4.       Defaults to java 1.5 regardless of which JDK is installed.
5.       The configuration section allows for customization by overriding the JDK version, memory settings etc.

              <!-- Override the target package name. -->
                                  <!-- Different for every plugin as the fields that they support can be different. -->
                                  <!-- Sometimes context sensitive help in IDE for this section is not available because it can be a Cdata field in XML. -->

10.0.4 Jar plugin

1.       Used to package our compiled code into a jar file.

2.       It is tied to the package phase of our build lifecycle.

3.       Configuration section allows for customization:
a.       Includes or Excludes – to only package certain things in your jar.
b.      Manifest – builds a manifest for our project. (useDefaultManifestFile)


10.0.5 Sources plugin

1.       Used to attach our source code to a jar.

2.       By default it is tied to the package phase.

3.       It is often overridden to a later phase like install or deploy so that the build is faster when we are developing.

                                  <!-- This is about WHEN the plugin is going to run -->

10.0.6 Javadoc plugin

1.       Used to attach Javadocs to a jar file when we upload them to our repository.

2.       It is tied to the package phase.

3.       It is often overridden to a later phase to speed up the build time while still developing the code.

4.       The defaults usually work out fine. Optionally, there are customization options for Javadoc format, like add company logo or change colors.