Monday, December 28, 2015

Playing With Maven

Maven is a powerful build tool for Java software projects. Actually, you can build software projects using other languages too, but Maven is developed in Java, and is thus historically used more for Java projects. Once you understand the core concepts, it is much easier to lookup the fine detail in the Maven documentation, or search for it on the internet.

Maven Overview – Core Concepts

Maven is centered around the concept of POM files (Project Object Model). A POM file is an XML representation of project resources like source code, test code, dependencies (external JARs used) etc. The POM contains references to all of these resources. The POM file should be located in the root directory of the project it belongs to.
Here is a diagram illustrating how Maven uses the POM file, and what the POM file primarily contains:
Overview of Maven core concepts.
Overview of Maven core concepts.
POM Files
When you execute a Maven command you give Maven a POM file to execute the commands on. Maven will then execute the command on the resources described in the POM.
Build Life Cycles, Phases and Goals
The build process in Maven is split up into build life cycles, phases and goals. A build life cycle consists of a sequence of build phases, and each build phase consists of a sequence of goals. When you run Maven you pass a command to Maven. This command is the name of a build life cycle, phase or goal. If a life cycle is requested executed, all build phases in that life cycle are executed. If a build phase is requested executed, all build phases before it in the pre-defined sequence of build phases are executed too.

Super POM

All Maven POM files inherit from a super POM. If no super POM is specified, the POM file inherits from the base POM. Here is a diagram illustrating that:
Super POM and POM inheritance.
Super POM and POM inheritance.

Maven Repositories

Maven repositories are directories of packaged JAR files with extra meta data. The meta data are POM files describing the projects each packaged JAR file belongs to, including what external dependencies each packaged JAR has. It is this meta data that enables Maven to download dependencies of your dependencies recursively, until the whole tree of dependencies is download and put into your local repository.
Maven repositories are covered in more detail in the Maven Introduction to Repositories, but here is a quick overview.
Maven has three types of repository:
  • Local repository
  • Central repository
  • Remote repository
Maven searches these repositories for dependencies in the above sequence. First in the local repository, then in the central repository, and third in remote repositories if specified in the POM.
Here is a diagram illustrating the three repository types and their location:
Maven Repository Types and Location.
Build Life Cycles
Maven has 3 built-in build life cycles. These are:
  1. default
  2. clean
  3. site
Each of these build life cycles takes care of a different aspect of building a software project. Thus, each of these build life cycles are executed independently of each other. You can get Maven to execute more than one build life cycle, but they will be executed in sequence, separately from each other, as if you had executed two separate Maven commands.
The default life cycle handles everything related to compiling and packaging your project. The clean life cycle handles everything related to removing temporary files from the output directory, including generated source files, compiled classes, previous JAR files etc. The site life cycle handles everything related to generating documentation for your project. In fact, site can generate a complete website with documentation for your project.
Build Phases
Each build life cycle is divided into a sequence of build phases, and the build phases are again subdivided into goals. Thus, the total build process is a sequence of build life cycle(s), build phases and goals.
You can execute either a whole build life cycle like clean or site, a build phase like install which is part of the default build life cycle, or a build goal like dependency:copy-dependencies. Note: You cannot execute the default life cycle directly. You have to specify a build phase or goal inside the default life cycle.
When you execute a build phase, all build phases before that build phase in this standard phase sequence are executed. Thus, executing the install build phase really means executing all build phases before the install phase, and then execute the install phase after that.
Build Phase Description
validate Validates that the project is correct and all necessary information is available. This also makes sure the dependencies are downloaded.
compile Compiles the source code of the project.
test Runs the tests against the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
package Packs the compiled code in its distributable format, such as a JAR.
install Install the package into the local repository, for use as a dependency in other projects locally.
deploy Copies the final package to the remote repository for sharing with other developers and projects.
Mvn Tricks and Tips :
mvn useful options
-h, –help Display help information
-o, –offline Work offline
-f, –fileForces the use of an alternate POM file
-s,–settingsAlternate path for the user settings file
-e, –errors Produce execution error messages
-X, –debug Produce execution debug output
-q, –quiet Quiet output – only show errors
Related to Plugins :
-npu, –no-plugin-updates Suppress upToDate check for any relevant registered plugins. Providing this option will have the affect of stabilizing Maven on all of the plugins versions that are currently available in a local Maven repository. With -npu active, Maven will not consult the remote repository for newer Maven versions.
-cpu, –check-plugin-updates Force upToDate check for any relevant registered plugins. Forces Maven to check for the latest released version of a Maven plugin. Not that this will not affect your build if you are explicitly specifying versions for Maven plugins in your project’s POM.
-up, –update-plugins Synonym for cpu.
Mvn dependency resolution :
  1. Max priority is given to groupid,Artifcat provided in pom
  2. In case multiple  jars of same groupid,artifact asre present jar with latest version is choosen
All About Classpath :
mvn dependency:copy-dependencies -DincludeScope=”test”     “any goal compile test runtime can be provided”
mvn -e -x “compile/test”
mvn dependency:build-classpath
mvn -e -X  “compile/test”
mvn install -p module1 , module2  build specific modules
mvn help:effective-pom       build the effective pom .
mvn dependency:analyze  shows dependencies which are declared and not used , used and not declared
mvn dependency:tree  shows complete list of dependency being used for  building
mvn version:display-dependency-updates figure  out which dependency have newer version releases
All About Scope :
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

No comments:

Post a Comment