m2_intro

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Maven 2Introduction : 

Maven 2Introduction Declarative Project Build

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Maven and Procedural Build Tools

Procedural Build Tools : 

Procedural Build Tools Ant, Make etc. Apply procedural steps to transit from sources to unlimited forms of artifacts: Compiled binaries, deployable units, generated code, tests output etc. Many reusable utilities to save on build development time Ant tasks, macros, etc. Similar to a development library

Procedural Build Tools Downsides : 

Procedural Build Tools Downsides No coherent methodology Every project makes up his own build process Lack of standards and best practices on how this should be done Unstructured process Duplication of functionality (despite reusable utilities) Need to manually tie the outcomes of various phases that have to work together mutually

But Ant is Working Just Fine! : 

But Ant is Working Just Fine! Ant provides building blocks for a toolset - Maven provides a working tool Ant has no build lifecycle, repositories, standard project layout, dependency management …you have to do it by yourself! Ant scripts quickly become complex Complex scripts are not reusable – duplication

MyApp – Ant Build File – 141 lines : 

MyApp – Ant Build File – 141 lines 141 Lines of code !!!

MyApp - Maven Build File – 17 lines : 

MyApp - Maven Build File – 17 lines 17 Lines of code

Maven vs. Ant : 

Maven vs. Ant Our experience shows 1:30 ratio in the number of LOC between Maven2 and Ant.

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Maven 2 Philosophy

What is Maven 2? : 

What is Maven 2? Project Management and Comprehension Tool (Maven 2 Development Team) A flexible and easy process, build tool A more standard way to build projects A dependency management tool A transparent best practices development guide A window to the project’s status & quality A documentation tool

Maven’s Primary Goal : 

Maven’s Primary Goal Maven's primary goal isto allow a developer to understand the complete state of a projectin the shortest period of time What is Maven’s project goal ?

The Primary Goal .. : 

The Primary Goal .. The way to achieve this goal is: Making the build process easy Providing a uniform build system Providing guidelines for best practices development Providing quality project information

Maven 2 Approach : 

Maven 2 Approach A holistic approach towards the development and build process Forms a “best practices” build infrastructure Provides coherent view of software projects in a standard uniform way

What Does Maven Standardize? : 

What Does Maven Standardize? Build lifecycle and order Project layout 3rd party dependencies storage Dependency resolution Transitive dependencies Project documentation and reports Common project tasks

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: The Project Object Model (POM)

Maven’s Declarative Nature : 

Maven’s Declarative Nature To provide standardization Maven takes a Declarative Approach In contrast to procedural build tools, such as Ant Similar to a complete development framework Project metadata is provided using a declarative XML document Metadata about project’s layout, execution, documentation etc. This declarative xml-based metadata is known as the POM – Project Object Model

The POM : 

The POM What is being built, not how Contains detailed metadata information about the project: Versioning Configuration management Dependencies Project structure Application and testing resources Developers/Contributors Issue tracking system Etc., etc.…

Sample POM : 

Sample POM

The POM (contd.) : 

The POM (contd.) POMs may inherent from each other Most metadata adheres to a W3C XML Schema (.xsd) Order of declaration between elements of the same level is not important in most cases Uses xsd:all

POM Properties : 

POM Properties May contain dynamic expressions:${some.expression} All elements in the model of the POM can be retrieved through properties, using XPATH-like syntax, e.g.: Normally the project. prefix can be omitted ${project.scm.url} ${project.version} ${settings.localRepository}

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: The Build Lifecycle

Build Lifecycle and Phases : 

Build Lifecycle and Phases Every build process/lifecycle is made up of several well-known phases The exact type of lifecycle phases and their order may vary according to the desired build output (project type) At every phase certain tasks are performed Such tasks are written as Maven plugins

Build Phases - Example : 

Build Phases - Example When you run the install phase, compile and test will also be run, as prior phases plugin-name:goal mvn install generate-sources compile test install deploy package compiler:compile mojo mojo mojo mojo bindings lifecycle

Lifecycle Importance : 

Lifecycle Importance The build lifecycle is a central point in Maven’s holistic approach Everything that happens as part of the build process must be bound to a certain phase in the lifecycle Most significant when writing Maven plugins

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Standard Project Layout

Maven’s Project Layout : 

Maven’s Project Layout Maven standardizes a recommended project layout May be overridden in the POM But is usually not desirable <build> <sourceDirectory>../../src</sourceDirectory> <testSourceDirectory>../../test</testSourceDirectory> </build> The standard layout is well-known and expected by any Maven user

Sample Project Layout : 

Sample Project Layout 4 nestedprojects Other projects src/ main/ java/ resources/ webapp/ application/ test/ java/ resources/ cactus/ site/

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Running Maven

The Maven Command Line : 

The Maven Command Line Maven is run through a simple CLI Under $M2_HOME/bin mvn -help

Maven Command Line Parameters : 

Maven Command Line Parameters POM file to execute is assumed to be ./pom.xml Can be overridden with –f, for example: Order of parameters and “–” flags is not important Can pass VM arguments with–Dmy.arg=value These are later available as Maven properties: ${my.arg} mvn –f build/mypom.xml ...

Command Line Phases & Goals : 

Command Line Phases & Goals Maven can either execute an entire phase with all its bound plugin goals Or a specific plugin goal The plugin can internally cause a run of a series of preliminary phases Can be combined in a single run: mvn install mvn plugin-alias:goal mvn clean source:jar install

More Info & Troubleshooting : 

More Info & Troubleshooting We can get Maven to be extremely verbose Useful mainly in tracking dependency resolution issues If a build error occurs, we can ask for the stack trace of the Java exception inside Maven mvn –X ... mvn ... -e

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Artifacts & Dependency Management

Artifacts : 

Artifacts Maven uses the notion of Artifact Artifacts may be any resource used by the build process or produced by it My refer to: Build outcomes Build dependencies (libs) Other resources Retrieved from artifact repositories

Artifact Identification : 

Artifact Identification An artifact is identified by its: Group ID Artifact ID Version Classifier (optional) Extension/Type For example: javax.servlet servlet-api 2.5 sources jar

Dependencies : 

Dependencies Special form of artifacts that are required by the build process Normally JAR libraries in Java-based builds Also include a “scope” attribute <dependency> <groupId>org.apache.wicket</groupId> <artifactId>wicket</artifactId> <version>1.3-incubating-SNAPSHOT</version> <type>jar</type> <scope>compile</scope> </dependency>

Dependency Scopes : 

Dependency Scopes Scope defines where in the build phases dependencies are available. 5 available scopes: compile – the dependency is available in all classpaths. The default scope. provided – the dependency is provided by the JDK or Container. runtime - the dependency is not required for compilation. It is in the runtime and test classpaths, but not the compile classpath. test – the dependency is available only in the test compilation and execution classpath. system - similar to provided except that the JAR path has to be stated explicitly.

Dependency Resolution : 

Dependency Resolution During the build process Maven will try to resolve the build dependencies When looking for dependency artifacts Maven consults 2 types of repositories: A local repository on the user’s machine A set of remote repositories

Dependency Version : 

Dependency Version A dependency version can be either: A release version A snapshot version A version range Versions affect the dependency resolution process <dependency> <groupId>org.apache.wicket</groupId> <artifactId>wicket</artifactId> <version>1.3-incubating-SNAPSHOT</version> </dependency>

Dependency Resolution by Version : 

Dependency Resolution by Version Release versions are retrieved only once from the repository Snapshot versions are assumed to be changing Automatically updated daily by default Can force update with mvn –U Version range is a concrete release version case: (,1.0] v <= 1.0 [1.2,1.3] 1.2 <= v <=1.3 [1.0,2.0) 1.0 <= v < 2.0 [1.5,) 1.5 <= v (,1.1),(1.1,) v != 1.1

Transitive Dependency : 

Transitive Dependency

Transitivity Exclusion : 

Transitivity Exclusion Can exclude dependencies from being transitively included <dependency> <groupId>org.codehaus.plexus</groupId> <artifactId>plexus-container</artifactId> <version>1.0</version> <exclusions> <exclusion> <groupId>org.codehaus.plexus</groupId> <artifactId>plexus-utils</artifactId> </exclusion> </exclusions> </dependency>

Dependency Graph->Tree : 

Dependency Graph->Tree Transitive dependencies result in a graph The help plugin can dump the graph as a tree: mvn help:dependencies

Building Multi-module Dependencies : 

Building Multi-module Dependencies Modules allow Maven to resolve dependencies not yet installed into the local repository Inter-dependent projects are built in one go and governed by a single “reactor” that is aware of all artifacts built so far Reactor executes build in the same order modules are specified <modules> <module>core</module> <module>webapp</module> <module>standalone</module> </modules>

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Sharing Dependencies – Repositories

Sharing Dependencies : 

Sharing Dependencies Sharing done through remote repositories Developer B needs A-v1 built by developer A in order to build module B -v1

Versioned Storage : 

Versioned Storage Always version (or version-range) based Developer B still depends on v1 of A Inter-module API is version-specific

Local Repository : 

Local Repository A repository stored locally on the machine The default is ~/.m2/repository Can be overridden in Maven’s settings.xml or by specifying-Dmaven.repo.local=/path/to/m2/repositoryto Maven Consulted first in dependency resolution Updated according to various update policies

Local Repository Layout : 

Local Repository Layout The repository assumes a standard layout To verify completeness artifacts include SHA1 checksum files

Remote Repositories : 

Remote Repositories Can be accessed by various protocols (http/s, ftp, ssh, filesystem, etc.) Maven provides an open transport layer of protocol providers - wagon Artifacts are deployed using wagon transports as well If communication is broken, the whole repository will be blacklisted for the current build session

Remote Repositories Layout : 

Remote Repositories Layout Contain metadata about releases, latest deployed artifact, etc.

Defining Remote Repositories : 

Defining Remote Repositories Repositories can be defined in: POMs Settings.xml Profiles (external or in settings) Mirrors (in settings)

Remote Repositories Properties : 

Remote Repositories Properties Do not use the same id for 2 or more repositories. Although Maven will not complain your build will become non-deterministic <repository> <id>jdk14</id> <name>Repository for JDK 1.4 builds</name> <url>http://www.myhost.com/maven/jdk14</url> <layout>default</layout> <snapshots> <enabled>true</enabled> </snapshots> </repository>

Plugin vs. Regular Repositories : 

Plugin vs. Regular Repositories Maven makes a difference between 2 kinds of remote repositories: Regular repositories, and Plugin repositories Implication on packaging of repository artifacts in build artifacts

Regular Repositories : 

Regular Repositories Contain artifacts needed for compiling and/or running the target software 3rd party libs Other modules Normally packaged with the resulting build artifact Licensing may need special attention since may be included in shipped software

Plugin Repositories : 

Plugin Repositories Contain plugin artifacts required for running maven goals Compile plugin, JavaDoc, code-gen etc. Never packaged with the resulting build artifact Updated similar to snapshots Has its own definition: <pluginRepository> <id>Maven Snapshots</id> <url>http://repo.mergere.com/maven2/</url> </pluginRepository>

Remote Repositories Update Policy : 

Remote Repositories Update Policy Remote artifacts are checked for updates according to the remote/plugin repository updates policy: Always Daily (default) interval:XXX (in minutes), or Never (only if does not exist locally) <repository> ... <updatePolicy>always</updatePolicy> </repository>

Remote Repositories Update Policy : 

Remote Repositories Update Policy Only snapshots and plugins are checked for updates according to the update policy Force snapshots update Force plugins update Disable plugins update mvn –up ... mvn –U ... mvn –npu ...

Built-in Remote Repositories : 

Built-in Remote Repositories By default Maven has 2 built-in repositories identified by the ids: “central” and “snapshots” These repositories are used by default in every build and are heavily loaded suffer from: Downtimes, network timeouts Broken or incomplete artifacts Invalid POM XML, bad checksums No authenticity of artifact source

Remote Repository Mirrors : 

Remote Repository Mirrors Both built-in and user-defined repositories are used during build To overcome repositories downtime/timeouts you can define mirrors inside settings.xml Mirroring is done by id: <mirrors> <mirror> <id>dotsrc.org</id> <url>http://mirrors.dotsrc.org/maven2</url> <mirrorOf>central</mirrorOf> </mirrors>

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: POM Inheritance

POM Inheritance : 

POM Inheritance One of the main strengths of Maven is the ability to create inheritance between POMs <parent> <artifactId>module-parent</artifactId> <groupId>org.snowflakes</groupId> <version>1.1-SNAPSHOT</version> </parent>

POM Inheritance (Contd.) : 

POM Inheritance (Contd.) POM inheritance creates a unified object model, made of the current running POM and all of its ancestors To dump and examine the actual runtime-constructed POM, you can use: mvn help:effective-pom

POM Inheritance (Contd.) : 

POM Inheritance (Contd.) POM inheritance is a useful technique to achieve reuse between modules: High-level POMs define project-wide or module-wide POM configuration: repositories, source control, common dependencies etc. Module-specific POMs inherit and customize

Parent POM Resolution : 

Parent POM Resolution You cannot use dynamic properties as part of parent POM declaration: All parents need to be resolved statically (like most OO-langs) <parent> <artifactId>${my.parent}</artifactId> <groupId>org.snowflakes</groupId> <version>1.1-SNAPSHOT</version> </parent>

Parent POM – Using RelativePath : 

Parent POM – Using RelativePath A parent POM optional relative path is a development-supporting info Helps retrieve the parent POM if it is not installed (in the local repository) Default value is ../pom.xml <parent> <relativePath>../parent/pom.xml</relativePath> <artifactId>${my.parent}</artifactId> <groupId>org.snowflakes</groupId> <version>1.1-SNAPSHOT</version> </parent>

Parent POM Resolution Order : 

Parent POM Resolution Order The order of parent POM resolution is: The reactor of currently building projects The relativePath location on the file system Maven will not complain if GroupId, artifactId or version do not match the POM data in the location given Will simply try the next resolution option Local repository Remote repositories

Dependency & Plugin Management : 

Dependency & Plugin Management We can define rules for dependency and plugin versions using the dependencyManagement and pluginManagement elements <dependencyManagement> <dependencies> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> </dependency> ... <dependencies> </dependencyManagement>

Dependency & Plugin Management : 

Dependency & Plugin Management Usually done in a parent POM Child POMs can repeat the dependency without specifying any version Without inheritance version would resolve to LATEST <dependencies> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> </dependency> ... <dependencies>

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Maven’s Cross-project Configuration

Settings.xml : 

Settings.xml Maven stores global, non-POM, configuration in settings.xml files What can be configured: Local repository location Remote repositories Network proxies Permissions and authentication details of servers Repository mirrors Profiles

Settings.xml : 

Settings.xml There are 2 settings.xml files: Global: $M2_HOME/conf/settings.xml User: ~/.m2/settings.xml The 2 files are merged in runtime User settings take precedence over global settings

Settings.xml (Contd.) : 

Settings.xml (Contd.) To view the runtime settings being used: Dynamic property values cannot be used in settings (Maven limitation) mvn help:effective-settings

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Profiles

Profiles : 

Profiles Profiles provide a convenient way to change the build behavior dynamically Profiles can be included in: Settings.xml (user & global) POMs External profiles descriptor profiles.xml under the project basedir Can be activated manually or automatically

Manual Profile Activation : 

Manual Profile Activation Using -P on the Maven CLI Defining active profiles in settings.xml mvn -P profileX,profileY ... <settings> ... <activeProfiles> <activeProfile>profileX</activeProfile> </activeProfiles> ... </settings>

Automatic Profile Activation : 

Automatic Profile Activation Using special activation directive By JDK version (prefix) By system property with/without a value <profile> <activation> <jdk>1.4</jdk> </activation> ... </profile> <profile> <activation> <property> <name>location</name> <value>tel-aviv</value> </property> </activation> ... </profile>

What Can Be Defined inside Profiles? : 

What Can Be Defined inside Profiles? In settings.xml or profiles.xml Repositories and pluginRepositories Properties In addition, pom.xmlprofiles can define dependencies plugins modules reporting dependencyManagement distributionManagement build subset: defaultGoal resources & testResources finalName

What Profiles are Active? : 

What Profiles are Active? Using the help plugin mvn ... help:active-profiles ...

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Installation & Deployment

Maven Install : 

Maven Install Installing is the process of storing artifacts into the local repository Installation can be manual or occur as a result of dependency resolution Manual install of a built artifact Runs all previous phases (package, compile…) Artifacts are usually produced into ${basedir}/target mvn clean install ...

Maven Install (Contd.) : 

Maven Install (Contd.) Manual install of a 3rd party artifact file Using the install-file mojo of the install plugin The installation process also creates: Checksum files Maven meta files with version info, etc. mvn install:install-file -DgroupId=group-id \ -DartifactId=artifact-id \ -Dversion=version \ -Dpackaging=packaging \ -Dfile=fileToInstall

Maven Deploy : 

Maven Deploy Deploying is the process of storing artifacts into a remote repository Deplyment is done according to a distribution management spec: <distributionManagement> ... <repository> <id>unique-repository-id</id> <name>human-readable-name</name> <url>wagon-url</url> </repository> ... </distributionManagement>

Maven Deploy (Contd.) : 

Maven Deploy (Contd.) Security credentials may be specified in settings.xml Deploy Previous phases will automatically run Usually combined with profiles to determine deployment destination mvn clean deploy ...

Manual File Deployment : 

Manual File Deployment Use the deploy plugin Similar to manual artifact install: mvn deploy:deploy-file -Durl=file://C:\m2-repo \ -DrepositoryId=some.id \ -Dfile=your-artifact-1.0.jar \ [-DpomFile=your-pom.xml] \ [-DgroupId=org.some.group] \ [-DartifactId=your-artifact] \ [-Dversion=1.0] \ [-Dpackaging=jar] \ [-Dclassifier=test] \ [-DgeneratePom=true] \ [-DgeneratePom.description=“Desc..."] \ [-DrepositoryLayout=legacy] \ [-DuniqueVersion=false]

POM Stored Inside A Repository : 

POM Stored Inside A Repository When installing or deploying a POM, the repository stores:The “effective POM” after all properties expansion, but without parent POM inclusion Still uses parent reference declaration The installed POM must be usable by people who don’t have the original execution environment (settings, profile files, system properties, etc.)

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Using Plugins

What is a Plugin? : 

What is a Plugin? A Plugin is a jar that contains MOJOs Maven Old Java Objects Each MOJO is equivalent to a goal and is identified by a unique goal name MOJOs are bound to build lifecycle phases perform the actual build work

MOJO Example : 

MOJO Example

Anno-Mojo : 

Anno-Mojo Java 5.0 annotations over doclets

Anno-Mojo Benefits : 

Anno-Mojo Benefits Inheritance & code reuse between plugins All the benefits of Java 5.0: Generics, auto-boxing Compile-time checks Delegation of execution to POJOs Natural Ant java tasks integration not XML based Source URL: http://mvn-anno-mojo.svn.sourceforge.net/viewvc/mvn-anno-mojo/trunk/

Calling Plugins Directly : 

Calling Plugins Directly The Plugin is identified as any other Maven artifact artifactId, groupId, version To call a plugin we use the plugin id and the goal id: Run the JavaDoc plugin’s javadoc MOJO mvn org.apache.maven.plugins:maven-javadoc-plugin:2.1:javadoc mvn groupId:artifactId:[version:]goal

Calling Plugins – Plugin Prefixes : 

Calling Plugins – Plugin Prefixes Maven assumes plugin prefix is used to save some typing For example, when typing – Maven will assume the plugin artifactId is maven-${prefix}-plugin, or what is specified in the plugin’s pom goalPrefix element, i.e.: mvn javadoc:javadoc mvn javadoc:maven-javadoc-plugin:LATEST:javadoc

Calling Plugins – Plugin Groups : 

Calling Plugins – Plugin Groups For groupId, Maven tries to locate the plugin in the repositories by iterating over pluginGroups in settings.xml The internal plugin groups org.apache.maven.plugins and org.codehaus.mojo are always checked <settings> ... <pluginGroups> <pluginGroup>myGroupId</pluginGroup> </pluginGroups> ... <settings>

Controlling Plugin Execution : 

Controlling Plugin Execution We can manually bind MOJOs to new build lifecycle phases Always in addition to any MOJO built-in phase bindings <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <executions> <execution> <phase>process-classes</phase> <goals> <goal>javadoc</goal> </goals> </execution> </executions> </plugin>

Plugin Configuration : 

Plugin Configuration Plugin can be configured either globally or per execution: <build> <plugins> <plugin> <groupId>groupId</groupId> <artifactId>artifactId</artifactId> <configuration/> <executions> <execution> <configuration/> ... </execution> </executions> </plugin> ... </plugins> </build>

Plugin Configuration : 

Plugin Configuration Configuration is an open element and is plugin specific For example, the compiler plugin can take: <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> ... </plugins> </build>

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Lifecycles & Packaging

Built-in Lifecycles : 

Built-in Lifecycles Maven has 3 built-in lifecycles: default clean site Each lifecycle defines a collection of phases that execute all their preceding phases The default lifecycles are defined inside org.apache.maven:maven-core under META-INF/plexus/components.xml

The Default Lifecycle : 

The Default Lifecycle The default lifecycle is the most commonly used in Java projects It has the following phases in order: validate generate-sources process-sources generate-resources process-resources compile process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile test package pre-integration-test integration-test post-integration-test verify install deploy

The Clean & Site Lifecycles : 

The Clean & Site Lifecycles The clean lifecycle has the following phases: pre-clean clean post-clean The site lifecycle has the following phases: pre-site site post-site site-deploy

Packaging : 

Packaging Lifecycles are merely static definitions To make use for them in runtime we need to bind plugin goals to the defined phases This is done using the packaging concept Packaging is defined in the POM: <project> <groupId>foo</groupId> <artifactId>bar</artifactId> <version>1.1</version> <packaging>war</packaging> ...

The Jar Packaging : 

The Jar Packaging Jar is the default packaging type (if unspecified) It defined the following goals-to-phase bindings: phase plugin-prefix:goal process-resources resources:resources compile compiler:compile process-test-resources resources:testResources test-compile compiler:testCompile test surefire:test package jar:jar install install:install deploy deploy:deploy

Custom Packaging : 

Custom Packaging Custom packaging can be defined in a META-INF/plexus/components.xml file and packaged into a plugin For example: <component-set> <components> <component> <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role> <role-hint>multijar</role-hint> ... <configuration> <phases> ... <compile>org.apache.maven.plugins:maven-compiler-plugin:compile</compile> ... <package>com.alphacsp.maven.plugins:jade-multijar-plugin:jar</package> ... </phases> </configuration> </component> ...

Custom Packaging (Contd.) : 

Custom Packaging (Contd.) When packaged into a plugin, the plugin must tell Maven it provides an extension (to the built-in packaging) This is done in the POM by: <packaging>multijar</packaging> ... <plugin> <groupId>bar</groupId> <artifactId>maven-multijar-plugin</artifactId> <extensions>true</extensions> </plugin> ...

Plugin Execution : 

Plugin Execution Another way to bind plugin goals to lifecycle phases is with the executions element of the plugin: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <executions> <phase>package</phase> <execution> <id>attach-sources</id> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>

Plugin Execution (Contd.) : 

Plugin Execution (Contd.) The phase can be omitted if the plugin developer already bound a Mojo to well-known phases in the plugin descriptor /** @phase package */ public class MyMojo { ... }

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Maven and Version Control

Maven SCM : 

Maven SCM Maven’s SCM - an API abstraction above Source Control Management Systems Supports most common SCMs CVS, SVN, Perforce, VSS, Clear Case, etc. Supports most common SCM operations checkout, tag, check in, remove, update, merge, etc. SCM operations can be controlled by running the maven-scm-plugin

Maven SCM Declaration : 

Maven SCM Declaration For example: For more documentation, see: http://docs.codehaus.org/display/SCM/SCM+Matrix http://maven.apache.org/scm/plugins/index.html <scm> <connection>read-only (no-commit) url</connection> <developerConnection>committer</developerConnection> <url>Browsable repo URL</url> </scm>

The Release Plugin : 

The Release Plugin Leverages Maven’s SCM transparency to control the process of releasing a new artifact version Check for no outstanding changes Change POM Tag version control Extend version history file Deploy artifact Deploy site Send mails to announce new release Change POM for next development (next version-SNAPSHOT)

The Release Plugin (Contd.) : 

The Release Plugin (Contd.) For more documentation, see: http://maven.apache.org/plugins/maven-release-plugin/

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Using Archetypes

Maven Archetypes : 

Maven Archetypes A bootstrapping plugin that enables quick creation of project skeletons Very useful for quickly creating new modules Archetype = project template An archetype is a normal artifact Stored and retrieved from a repository

Available Archetypes : 

Available Archetypes Easy to package new archetype types Based on Velocity templates

Creating an Archetype : 

Creating an Archetype Run the archetype plugin For example mvn archetype:create -DarchetypeGroupId=archetypeGroupId \ -DarchetypeArtifactId=archetypeArtifactId \ -DarchetypeVersion=archetypeVersion \ -DgroupId=newProjectGroupId \ -DartifactId=newProjectArtifactId mvn archetype:create -DarchetypeGroupId=org.apache.myfaces.maven \ -DarchetypeArtifactId=maven-archetype-myfaces \ -DarchetypeVersion=1.0-SNAPSHOT \ -DgroupId=myAppId \ -DartifactId=testApp

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Site & Project Reports

Site Reports : 

Site Reports Meta-information for users and developers name, version, date Dependencies Mailing Lists & newsgroups Continous Integration Source Repository Issue Tracking Project Team License User and developer documentation changelog, version history, release notes documentation JavaDoc Project health and quality reports test reports style reports metrics project-info-reports

Site Reports Creation : 

Site Reports Creation Plugins that generate reports need to be added inside a special reporting section For example, to generate POM-derived reports: ... <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-project-info-reports-plugin</artifactId> </plugin> </plugins> </reporting> ...

Site Content Creation : 

Site Content Creation Edit site content in apt - “almost plain text”, WIKI style editing fml – FAQ generation format +- src/ +- site/ +- apt/ | +- index.apt | +- xdoc/ | +- other.xml | +- fml/ | +- general.fml | +- faq.fml | +- site.xml

Site Navigation Creation : 

Site Navigation Creation Create a site descriptor src/site/site.xml Controls site layout and navigation menus ... <menu name="Maven 2.0"> <item name="Introduction" href="index.html"/> <item name="Download" href="download.html"/> <item name="Release Notes" href="release-notes.html" /> <item name="General Information" href="about.html"/> <item name="Road Map" href="roadmap.html" /> </menu> ${reports} ...

Generation & Deployment : 

Generation & Deployment To generate a site To deploy a site Add site distribution section in POM Then run the deploy goal mvn site <distributionManagement> <site> <id>website</id> <url>scp://www.mycompany.com/www/docs/project/</url> </site> </distributionManagement> mvn site-deploy

Site Examples – Code Coverage : 

Site Examples – Code Coverage

Site Examples – Surefire Report : 

Site Examples – Surefire Report

Site – Custom Look & Feel : 

Site – Custom Look & Feel

Maven Site Plugin : 

Maven Site Plugin For more documentation, see: http://maven.apache.org/plugins/maven-site-plugin/

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: : 

:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: IDE Support

Maven IDE Plugins : 

Maven IDE Plugins Maven has very useful plug-ins for IDE project generation IntelliJ IDEA Eclipse NetBeans

Generated Project Files : 

Generated Project Files The generated IDE projects are aligned with the POM definitions All the dependencies 3rd party/internal Dependency source and javadoc linking Custom module settings WAR, EJB, EAR, etc. The generated project is ready to compile, test, debug and run The POM is the single source of information!

Maven IDE Plugins : 

Maven IDE Plugins For more information, see: http://maven.apache.org/plugins/maven-idea-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/

Thank You! : 

Thank You! Q & A

authorStream Live Help