introduction to maven, its configuration, lifecycle and relationship to js world

Maven technical sessionDmitry�� Bakaleinik January�� 2015

Mavenexpert; know-it-all

Coming from the Hebrew word Hebrew מבין (mevin), maven can have two definitions.

In common contexts means "expert". However, in sarcastic settings, it is used as “know-it-all”.

– Yiddish Slang Dictionary

The maven project was originally started as an attempt to simplify the build processes.

Maven addresses two aspects of building software: First, it describes how software is built, and second, it describes its

dependencies.

pom.xml

compiled codeartifact jar/war/

othertests coveragedocumentationquality report

What maven can do?Centralize project information such as build metadata, properties, version control systems, developers in project object model file (pom.xml).

Manage our build process; does project build tasks such as compilation, unit testing, integration testing, quality metrics, documentation generation as it required for the successful delivery.

Manage project library and resources dependencies.

Manage project artifacts deployment to corporate/public repositories.

Maven pluginsMaven is actually a plugin execution framework where every task is actually done by plugins.

A plugin provides a set of actions or commands (in maven terminology called goals) that can be executed to perform a task.

There are plugins for building, testing, source control management, running a web server, generating project files and much more.

Some basic plugins are included in every project by default, and they have sensible default settings.

Maven plugins suiteCoreclean

compilerdeployfailsafeinstall

resourcessite

surefireverifier

ReportingChangelog

ChangesCheckstyle

CloverJavadocs

PMDSurefire-reports

Local serversCargojaxmejetty

tomcat

ToolsAnt

AntlrAntrun

ArchetypeAssembly

HelpRelease

Packagingjar war ear ejbrar pom shade

IDE integrationeclipse

idea

Maven plugins suiteCoreclean

compilerdeployfailsafeinstall

resourcessite

surefireverifier

ReportingChangelog

ChangesCheckstyle

CloverJavadocs

PMDSurefire-reports

Local serversCargojaxmejetty

tomcat

ToolsAnt

AntlrAntrun

ArchetypeAssembly

HelpRelease

Packagingjar war ear ejbrar pom shade

IDE integrationeclipse

idea

And�� much�� more…⋯

Maven plugin goals

Maven plugin goalsA plugin generally provides a set of goals and which can be executed using following syntax:mvn [plugin-name]:[goal-name]


For example, a Java project can be compiled with the maven-compiler-plugin's compile-goal by running following command:my-project-dir> mvn compiler:compile


For example, a Java project can be compiled with the maven-compiler-plugin's compile-goal by running following command:my-project-dir>

You can get information about plugin and its goals using maven help plugin:mvn help:describe -Dplugin=compiler

Project Object Model (POM)

Project Object Model (POM)A Project Object Model or POM is the fundamental unit of work in Maven.

It’s an XML file that contains information about the project and configuration details used by Maven to build the project.

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.

When executing a task or goal, Maven looks for the POM in the current working directory, but you can explicitly tell to maven path of POM file: mvn -f <path/to/pom.xml>

Simplest pom.xml

Coordinates. What???

Every maven project is identified by its GAV coordinates.

groupId (G) - It’s an identifier for a collection of related modules. This is usually a hierarchy that starts with the organization that produced the modules, and then possibly moves into increasingly more specialized projects, e.g. com.sap.ui5 or com.sap.fiori.

G A V


artifact (A) - It’s a unique identifier or a simple name that is given to a module within a group

There can be multiple modules in a group.If a group has a module called webapp, its artifactId will be “webapp”.

G A V


version (V) - It’s an identifier for the release or build number of project, e.g. 1.0 or 1.0-SNAPSHOT

G A V


version (V) - It’s an identifier for the release or build number of project,e.g. 1.0 or 1.0-SNAPSHOT

Now what’s this SNAPSHOT?

G A V

Versioning strategy

There are two types of versions: release and snapshot.

Releases - a version that is assumed never to change.Only to be used for a single state of the project when it is released and then updated to the next snapshot

Snapshot - used by projects during development as it implies that development is still occurring that project may change

G A V

Simplest pom.xml

Simplest pom.xml

mvn install

Simplest pom.xml

mvn install {compile code

run tests

package as jar

deploy to local repo

How all this can be done from 6 lines of xml?

Super POM

Super POM

The modelVersion property defines the super POM file (org/apache/maven/model/pom-4.0.0.xml)

Super POM


Standard�� directory�� layout

Super POM


propertiesinterpolation

Super POM


Super POM


Work with the same analogy as objects inheritance

Effec%ve'POM'

POM'

Parent'POM'

Super'POM'

Super POM


Work with the same analogy as

To see the merged pom: mvn help:effective-pom Effec%ve'POM'

POM'

Parent'POM'

Super'POM'

Property referencesenv.*Environment variables exposed by OS or Shell${env.JAVA_HOME}

project.*POM elemens${project.groupId} ${project.parent.groupId}

settings.*Maven settings.xml properties ${settings.localRepository}

Custom properties ${foo}

Build LifecycleIn maven, the build is run is a predefined ordered set of steps called the build lifecycle.

The individual steps are called phases and the same phases are run for every maven build using the default lifecycle, no matter what it produce.

The build task that will be performed during each phase are determined by the configuration in the project file, and in particular in the selected packaging.

Build lifecycleValidate •  Validate the project is correct

and all necessary information is available

Compile •  Compile the source code of

the project

Test •  Test the compiled code using

a suitable unit testing framework. These tests should not require the code be packaged or deployed

Package •  Take the compiled code and

package it in distributable format, such as a JAR

Integration-test •  Process and deploy the

package if necessary into a environment where integration tests can run

Verify •  Run any checks to verify the

package is valid and meets the quality criteria

Install •  Install the package into the

local repository, for use as a dependency for other projects locally

Deploy •  Done in integration or release

environment, copies the final package to the local repository, then deploy the installed package in a specified environment.

Default Lifecycle

(collection of build phases)

Build lifecycle

mvn install

Validate •  Validate the project is correct



the project












environment, copies the final package to the local repository, then deploy the installed package in a specified environment. X

Build lifecycleValidate •  Validate the project is correct



the project












environment, copies the final package to the local repository, then deploy the installed package in a specified environment. X mvn clean install

+Pre-clean

Clean • Remove all

previous build files Post-clean

MappingLifecycle

Clean Validate Compile

Test Package Integration-test

Verify Install Deploy

jslint plugin

jslint

Compiler plugin

compile testCompile

Cargo plugin

deploy run

MappingLifecycle




Clean plugin

clean

jslint plugin

jslint

Compiler plugin

compile testCompile

Cargo plugin

deploy run

MappingLifecycle




Clean plugin

clean

Each plugin comeswith its goals bound

to lifecycle phases

In�� maven�� terminology�� such�� binding�� called�� MOJO�� Its�� also�� predefines�� goal�� configuration

jslint plugin

jslint

Compiler plugin

compile testCompile

Cargo plugin

deploy run

MappingLifecycle




Clean plugin

clean


to lifecycle phases

jslint plugin

jslint

MappingLifecycle





to lifecycle phases

jslint plugin

jslint

MappingLifecycle





to lifecycle phasesTIP: to disable a preconfiguredplugin executionchange phase to“none”

Package type

The specific goals bound to each phase default to a set of goals specific to a project’s packaging.

Package type

The specific goals bound to each phase default to a set of goals specific to a project’s packaging.

A project with packaging jar has a different set of default goals from a project with a packaging of war. The packaging element affects the steps required to build a project.

Package type

Package type

JAR is the default packaging type, the most common, and thus the most commonly encountered lifecycle configuration.

Package type

JAR is the commonly encountered lifecycle configuration.

POM is the simplest packaging type. The artifact that it generates is itself only, rather than a JAR, SAR, or EAR. There is no code to test or compile, and there are no resources the process.

Package type

JAR is the commonly encountered lifecycle configuration.

POM is the simplest packaging type. The artifact that it generates is itself only, rather than a JAR, SAR, or EAR. There is no code to test or compile, and there are no resources the process.

The WAR packaging type is similar to the JAR type. The exception being the package goal of war:war. Note that the war:war goal requires a web.xml configuration in your src/main/webapp/WEB-INF directory.

Package type

Dependencies mechanism

The cornerstone of the POM is its dependency list. Because most every project depends upon others to build and run correctly.

It happens with the Coordinates!

DependenciesOne powerful aspect of Maven is in its handling of project relationships; that includes inheritance, aggregation (multi-module projects) and dependencies (it also includes transitive dependencies).


Whats it transitive dependencies?Maven brings the dependencies of the project dependencies, allowing your dependency list to focus solely on project requirements.


Whats it transitive dependencies?Maven brings the dependencies of the project dependencies, allowing your dependency list to focus solely on project requirements.

Dependency management has a long tradition of being a complicated mess for anything but the most trivial of projects. Maven solves both problems through a common local repository from which to link projects correctly, versions and all.

Scopescompile provided

runtime test

system import

Compile Test Runtime

Classpath


runtime test

system import


Classpath

This is the default scope, used if none is specified. Compile dependencies are available in all classpaths. Furthermore, those dependencies are propagated to dependent projects.


runtime test

system import


Classpath

This is much like compile, but indicates you expect the JDK or a container to provide it at runtime. It is only available on the compilation and test classpath, and is not transitive.


runtime test

system import


Classpath

This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.


runtime test

system import


Classpath

This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.


runtime test

system import


Classpath

This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.


runtime test

system import


Classpath

This scope used to import dependencies defined in configuration of the other project


runtime test

system import


Classpath

RepositoriesLocal repository in %USER_HOME%/.m2/repository

Remote repositoryExample: http://repo1.maven.org/maven2 oranother internal company repository, like nexus.wdf.sap.corp

The repository contains dependencies and plugins, can store any kind of artifact: jar, war, pom, ejb, ear.

The repository can be managed by a “repository manager” like Nexus

http://repo1.maven.org/maven2

Lifecycle

Maven

Project

pom.xml

source code

Lifecycle

Maven

Project

pom.xml

source code

reads the configuration

Lifecycle

Maven

Project

pom.xml

source code

fetches the dependencies

M2 local repo

Lifecycle

Maven

Project

pom.xml

source code M2 local repo

NEXUS

fetches missing dependencies from the Internet into M2

Lifecycle

Maven

Project

pom.xml


NEXUStarget folder

copies the dependencies

Lifecycle

Maven

Project

pom.xml


NEXUStarget folder

build the project

Lifecycle

Maven

Project

pom.xml


NEXUStarget folder

deploys artifact to local repository

Lifecycle

Maven

Project

pom.xml


NEXUStarget folder

InheritanceParent Project

Child Project

Extends

AggregationProject A

Project B

Project C

cd Amvn clean installcd .. cd Bmvn clean installcd ..cd C mvn clean install

Depends

Depends } 8 lines!!!

AggregationProject A

Project B

Project C

Reactor

Debugging maven

Output full error stack trace:maven <anygoal> -e

Output for debugging maven <anygoal> -X

settings.xmlThe settings.xml file contains configuration of Maven execution. Settings in this file are settings which apply to many projects and which should not be bundled to any specific project, or distributed to an audience. These include values such as the local repository location, alternate remote repository servers, and authentication information.


Maven provides 2 settings files:Local settings.xml at %USER_HOME%/.m2/settings.xmlGlobal settings.xml at %M2_HOME%/conf/settings.xml



These files are not bundled with Maven project and don’t get distributed




If both files exists, their content get merged




If both files exists, their content get merged

Local settings.xml overrides the global one

Common criticism of mavenPoor documentation - Lots of maven documentation is automatically generated and is generally pretty horrible.

Simple things are pretty counterintuitive in maven, e.g. copying a file

Maven adds to the number of places you need to look when something breaks - both your source code, local repository and the remote repository.

Everything breaks if someone changes an artifactId or groupId

Doesn’t work well if your network connectivity is unreliable or unavailable

A huge output log

Maven + NPM + Grunt

eirslett/frontend-maven-plugin

This plugin downloads/installs Node and NPM locally for your project, runs NPM install, installs bower dependencies, run Grunt and/or gulp and/or Karma. It's supposed to work on Windows, OS X and Linux.

Thanks

introduction to maven, its configuration, lifecycle and relationship to js world

Software

mvn plugin

maven help plugin

java project

project information

project library

project files

projectdir mvn compiler

maven pluginsmaven