Saturday, April 18, 2009

Mercurial & Maven

Tutorial - Cloning a repository

(This page is part 2 of 9 of the Tutorial series. Previous part is TutorialInstall, next part is TutorialHistory)

You have followed TutorialInstall to install Mercurial already, right? Good!

In Mercurial, we do all of our work inside a repository. A repository is a directory that contains all of the source files that we want to keep history of, along with complete histories of those source files.

The easiest way to get started with Mercurial is to use a repository that already contains some files and some history.

To do this, we use the clone command. This makes a clone of a repository; it makes a complete copy of another repository so that we will have our own local, private one to work in.

Let's clone a small "hello, world" repository hosted at selenic.com:

$ hg clone http://www.selenic.com/repo/hello my-hello 

If all goes well, the clone command prints this (Mercurial 1.0):

requesting all changes adding changesets adding manifests adding file changes added 2 changesets with 2 changes to 2 files updating working directory 2 files updated, 0 files merged, 0 files removed, 0 files unresolved 

We should now find a directory called my-hello in our current directory:

$ ls my-hello 

Inside the my-hello directory, we should find some files:

$ ls my-hello Makefile  hello.c 

These files are exact copies of the files in the repository we just cloned.

Note: in Mercurial, each repository is self-contained. When you clone a repository, the new repository becomes an exact copy of the existing one at the time of the clone, but subsequent changes in either one will not show up in the other unless you explicitly transfer them, by either pulling or pushing.

By default, hg clone checks out (see Update) the tipmost revision of the repository into the repository's working directory. To see which revision is currently checked out, we can use the parents command:

$ cd my-hello $ hg parents changeset:   1:82e55d328c8c tag:         tip user:        mpm@selenic.com date:        Fri Aug 26 01:21:28 2005 -0700 summary:     Create a makefile 

At this point, we can start examining some of the history of our new repository, by continuing to TutorialHistory.


Maven in 5 Minutes

Installation

Maven is a Java tool, so you must have Java installed in order to proceed.

First, download Maven and follow the installation instructions. After that, type the following in a terminal or in a command prompt:

mvn --version 

It should print out your installed version of Maven, for example:

Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" 

Depending upon your network setup, you may require extra configuration. Check out the Guide to Configuring Maven if necessary.

Creating a Project

On your command line, execute the following Maven goal:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app 

If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading the most recent artifacts (plugin jars and other files) into your local repository. You may also need to execute the command a couple of times before it succeeds. This is because the remote server may time out before your downloads are complete. Don't worry, there are ways to fix that.

You will notice that the create goal created a directory with the same name given as the artifactId. Change into that directory.

cd my-app 

Under this directory you will notice the following standard project structure.

my-app |-- pom.xml `-- src     |-- main     |   `-- java     |       `-- com     |           `-- mycompany     |               `-- app     |                   `-- App.java     `-- test         `-- java             `-- com                 `-- mycompany                     `-- app                         `-- AppTest.java 

The src/main/java directory contains the project source code, the src/test/java directory contains the test source, and the pom.xml is the project's Project Object Model, or POM.

The POM

The pom.xml file is the core of a project's configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively. This project's POM is:

   4.0.0   com.mycompany.app   my-app   jar   1.0-SNAPSHOT   Maven Quick Start Archetype   http://maven.apache.org               junit       junit       3.8.1       test          

What did I just do?

You executed the Maven goal archetype:create, and passed in various parameters to that goal. The prefix archetype is the plugin that contains the goal. If you are familiar with Ant, you may concieve of this as similar to a task. This goal created a simple project based upon an archetype. Suffice it to say for now that a plugin is a collection of goals with a general common purpose. For example the jboss-maven-plugin, whose purpose is "deal with various jboss items".

Build the Project

mvn package 

The command line will print out various actions, and end with the following:

 ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2 seconds [INFO] Finished at: Thu Oct 05 21:16:04 CDT 2006 [INFO] Final Memory: 3M/6M [INFO] ------------------------------------------------------------------------ 

Unlike the first command executed (archetype:create) you may notice the second is simply a single word - package. Rather than a goal, this is a phase. A phase is a step in the build lifecycle, which is an ordered sequence of phases. When a phase is given, Maven will execute every phase in the sequence up to and including the one defined. For example, if we execute the compile phase, the phases that actually get executed are:

  1. validate
  2. generate-sources
  3. process-sources
  4. generate-resources
  5. process-resources
  6. compile

You may test the newly compiled and packaged JAR with the following command:

java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App 

Which will print the quintessential:

Hello World! 

Running Maven Tools

Maven Phases

Although hardly a comprehensive list, these are the most common default lifecycle phases executed.

  • 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.

There are two other Maven lifecycles of note beyond the default list above. They are

  • clean: cleans up artifacts created by prior builds
  • site: generates site documentation for this project

Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the packaging type of the project. For example,package executes jar:jar if the project type is a JAR, and war:war is the project type is - you guessed it - a WAR.

An interesting thing to note is that phases and goals may be executed in sequence.

mvn clean dependency:copy-dependencies package 

This command will clean the project, copy dependencies, and package the project (executing all phases up to package, of course).

Generating the Site

mvn site 

This phase generates a site based upon information on the project's pom. You can look at the documentation generated under target/site.

No comments: