introduction to maven

Download Introduction to maven

Post on 30-Aug-2014




1 download

Embed Size (px)




  • Introduction to Maven Manolis Georgopoulos 20/09/2013
  • Maven what ? Official site says that: Apache Maven is a software project management and comprehension tool. 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.
  • What ??????? Maven is : o A top-level open source Apache Software Foundation project o A popular build tool o A dependency management tool o A release management tool The picture describes the Maven operation and interaction model.
  • Why Maven? Dependency management Modularity Code reusability Abstraction of Build process (no dependency on IDEs) Automated processes (deployments, unit & integration tests, etc)
  • Project Structure src/main/java: Your Java source code goes here src/main/resources: Other resources your application needs. All directories or files placed within the src/main/resources directory are packaged in your JAR with the exact same structure, starting at the base of the JAR src/main/filters: Resource filters, in the form of properties files, which may be used to define variables only known at runtime src/main/config: Configuration files. The directory [src/main/config] doesn't show up on the classpath so the application or test classes can't read anything in it. src/main/webapp: The Web application directory for a WAR project src/test/java: Unit tests (will not be deployed) src/test/resources: Resources to be used for unit tests, but will not be deployed src/test/filters: Resources filters to be used for unit tests, but will not be deployed src/site: Files used to generate the Maven project Website
  • Key Concepts POM Artifacts Dependencies Lifecycle phases Plugins Profiles
  • POM POM o Stands for Project Object Model o Is Mavens description of a single project o Is an XML document o Contains a detailed description of your project, including information about versioning and configuration management, dependencies, application and testing resources, team members and structure, and much more
  • POM basic elements project the top level element modelVersion - the version of the object model groupId indicates the unique identifier of the organization or group that created the project artifactId indicates the unique name of the primary artifact being generated by this project packaging indicates the package type to be used by this artifact (jar, war, ear, etc). Default value is jar version indicates the version of the artifact generated by the project name indicates the display name used for the project url indicates where the projects site can be found description provides a basic description for the project *
  • Artifacts An artifact is a file (jar, war, ear, etc), that gets deployed to a Maven repository. Maven provides a large database of artifacts in maven central repository Artifact Repository Sonatype Nexus 2.3.x Proxies maven central repository Proxies other third party repositories (Apache, jBoss, etc) Repository for Snapshot artifacts Repository for Release artifacts Repository types Maven has two types of repositories: local and remote. Maven usually interacts with your local repository, but when a declared dependency is not present in your local repository Maven searches all the remote repositories it has access to in an attempt to find whats missing.
  • Dependencies Dependency Management The key concept is that Maven dependencies are declarative. In the POM you are not specifically telling Maven where the dependencies are physically, you are simply telling Maven what a specific project expects. Where does that dependency come from ? When a dependency is declared, Maven tries to satisfy that dependency by looking in all of the remote repositories that are available, within the context of your project, for artifacts that match the dependency request. If a matching artifact is located, Maven transports it from that remote repository to your local repository for general use. Transitive dependencies Transitive dependencies are a feature introduced in Maven 2.0. This allows you to avoid needing to discover and specify the libraries that your own dependencies require, and including them automatically.
  • Dependencies - Scope In a real-world enterprise application, you may not need to include all the dependencies in the deployed application. Some JARs are needed only for unit testing, while others will be provided at runtime by the application server. Using a technique called dependency scoping, Maven lets you use certain JARs only when you really need them and excludes them from the classpath when you don't. Maven provides four dependency scopes: compile: A compile-scope dependency is available in all phases. This is the default value. provided: A provided dependency is used to compile the application, but will not be deployed. You would use this scope when you expect the JDK or application server to provide the JAR. The servlet APIs are a good example. runtime: Runtime-scope dependencies are not needed for compilation, only for execution, such as JDBC (Java Database Connectivity) drivers. These dependencies will be packaged in the final archive (e.g. will be packages in a War or Ear archive) test: Test-scope dependencies are needed only to compile and run tests (JUnit, for example).
  • Lifecycle phases Basic phases: validate - validate the project is correct and all necessary information is available compile - compile the source code of the project test - test the compiled source 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 its distributable format, such as a JAR. integration-test - process and deploy the package if necessary into an environment where integration tests can be run verify - run any checks to verify the package is valid and meets quality criteria install - install the package into the local repository, for use as a dependency in other projects locally deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects. These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle.
  • Plugins Core maven plugins: Compiler plugin Surefire plugin EJB plugin War plugin EAR plugin Other plugins: Release plugin War overlay plugin Resources plugin Plugins are downloaded and installed automatically, if not present on your local system, in much the same way that a dependency is handled. ${home.repository}.m2repositoryorgapachemavenplugins API for creating your own maven plugins.
  • Plugins compiler plugin Used to compile the source files org.apache.maven.pluginsmaven-compiler-plugin2.01.61.6
  • Plugins surefire plugin Used to run Tests. org.apache.maven.pluginsmaven-surefire-plugin2.12.2 . * Note that the Surefire plugin (which executes the test) looks for tests contained in files with a particular naming convention. By default, the following tests are included: **/* **/Test*.java **/* * To execute one Test at a time, run mvn test -Dtest=MyUnitlTest
  • Plugins ejb plugin Used to create EJB artifacts org.apache.maven.pluginsmaven-ejb-plugin${maven.ejb.plugin.version}3.1
  • Plugins war plugin Used to create WAR artifacts org.apache.maven.pluginsmaven-war-plugin2.4webApplicationWEB-INF/lib/*.jar
  • Plugins ear plugin Used to create EAR artifacts org.apache.maven.pluginsmaven-ear-pluginmyEARmyEARtruelibtrue6com.manolismain/main.jarcom.manoliswebweb.war//web
  • Profiles Profiles are Maven's way of letting you create environmental variations in the build life cycle to accommodate things like building on different platforms, building with different JVMs, testing with different databases, or referencing the local file system. Typically you try to encapsulate as much as possible in the POM to ensure that builds are portable, but sometimes you simply have to take into consideration variation across systems and this is why profiles were introduced in Maven. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and can be activated in several ways. Profiles modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the application server root in the d