• Installed Eucalyptus, an Infrastructure-as-a-Service offering, and
• Configured Eucalyptus to start VMs with IP addresses from a private VLAN

Before we jump into bundling, uploading, and registering images, let’s first download and install Euca2ools.

Euca2ools

Euca2ools are command-line utilities to help:

• Manage Images (bundle, upload, register, delete, etc.)
• Manage Instances (start, reboot, terminate, list, etc.)
• Manage Volumes & Snapshots (attach, detach, list, create, delete, etc.)
• Manage IP addresses (associate, disassociate, list, etc.)
• Manage SSH key pairs (add, delete, list)
• Manage Security groups (add, delete, list, add rules)
• Query availability zones (clusters)

Euca2ools is compatible with Amazon EC2 and S3 web services. In fact, Euca2ools is modeled after Amazon EC2 API and EC2 AMI tools.

Download & Install

Since I have been using CentOS 5 32-bit, I’ll describe the tar ball install process for CentOS 5. Also, in my case I’ll install euca2ools on my front-end machine (192.168.0.114)

Note: You may choose to go the yum (you will need to add the http://www.eucalyptussoftware.com/downloads/repo/euca2ools/$VERSION/yum/centos/ repo first) route instead of the tar ball.

Note: If you are using a Debian-based distro, feel free to install using apt-get (apt-get install euca2ools)

First download the tar.gz package for CentOS 5 32-bit – in this case, euca2ools-1.2-centos-i386.tar.gz

Next un-tar the above package

tar zxvf euca2ools-1.2-centos-i386.tar.gz

Before you install the rpm packages in the euca2ools-1.2-centos-i386 directory, you need to install swig as follows:

yum update
yum install swig

Next, go into euca2ools-1.2-centos-i386 directory and install the rpm packages as follows:

cd euca2ools-1.2-centos-i386
rpm -Uvh python25-2.5.1-bashton1.i386.rpm python25-libs-2.5.1-bashton1.i386.rpm euca2ools-1.2-1.i386.rpm

Confirm that euca2ools is install as follows:

rpm -qa euca2ools

Testing Euca2ools

In the first post I used Amazon EC2 API tools to test the Eucalyptus install. To be precise I had used the ec2-describe-availability-zones command.

Now that we have Euca2ools installed we can use the euca-describe-availability-zones command instead. Remember to source in the eucarc file first.

cd .euca
source eucarc
euca-describe-availability-zones verbose

Nice!

Feel free to play around with some of the other commands. You can get a list of commands by typing “euca” and pressing the TAB button twice. You could also run the command ls /usr/bin | grep euca

To get more information on a particular command, type in the command name following by the argument –help. For instance:

euca-describe-availability-zones --help

As we continue these series, we will see more and more of the Euca2ools commands.

Update fabric/far version
The update fabric/far version goal of the Appistry CloudIQ Maven plugin automates the version update of the fabric/far artifact and integrates this process into the Maven build life-cycle of the CloudIQ artifact.

During development or build/run/test cycle, the process of manually having to update the version of the fabric/far becomes painful real quick. And heaven forbid that your forget to update the version and attempt a deploy – Appistry CloudIQ rejects the artifact with a nasty message stating that the version that you are attempting to deploy is older than the version it has currently.

The cloudiq:update-far-version goal alleviates the above problem by automating the update of the version value.

Usage
To update the version of the fabric/far application, run this goal as:

mvn cloudiq:update-far-version

Assuming you have configured the Appistry CloudIQ Maven plugin as follows in your project pom:

<build>
    <plugins>
        <plugin>
		<groupId>com.appistry.maven.plugins</groupId>
		<artifactId>maven-cloudiq-plugin</artifactId>
		<version>0.0.1-SNAPSHOT</version>
		<configuration>
			<appName>CreditRules_App</appName>
			<appFilename>CreditRules_App</appFilename>
			<remoteSshHost>192.168.5.55</remoteSshHost>
			<remoteSshPort>22</remoteSshPort>
			<remoteSshUsername>fabricuser</remoteSshUsername>
			<remoteSshPassword>fabricuser</remoteSshPassword>
			<!--
				<farVersionUpdateSkip>false</farVersionUpdateSkip>
				<farVersion>99</farVersion>
			-->
		</configuration>
	</plugin>
</plugins>
</build>

the mvn package cloudiq:update-far-version command will update (increment by 1) the version value in the fabric/far application descriptor (in this case, CreditRules_App.xml). Currently the only requirement is that the version defined in the application descriptor is an integer. We will talk a little more about this requirement a little later.

Note: This goal (cloudiq:update-far-version) is part of the cloudiq:package goal which essentially performs the following:

1. copies the resources/scripts files (cloudiq:copy-resources goal) to a work directory,
2. updates the version of the fabric/far application descriptor (cloudiq:update-far-version goal),
3. gathers the dependent (if any) jars (cloudiq:assemble-dependencies goal), and
4. runs fabric_pkg to create the actual fabric/far artifact.

99.99% of the time you will run the cloudiq:package goal which as described above will update the version and package the app as a deployable CloudIQ artifact.

Configuration
The cloudiq:update-far-version goal does not need any configuration since all it does is read the existing version and increment it. But there are some configuration parameters around this goal that come in handy when needed.

farVersionUpdateSkip
Setting this parameter to true will skip the execution of the cloudiq:update-far-version goal. This comes in handy if you want to update the version by hand or using some other process. The default is false i.e. the version gets updated when either cloudiq:package goal or cloudiq:update-far-version goal is run.

farVersion
This parameter allows you to specify a version that will be used and hence overrides the default behavior of the cloudiq:update-far-version goal which is to increment the version by 1.
This parameter takes a string as it value. That’s right, a String rather than an integer. So you could set it to a value like “1.0″ or “5.0.2″.
I generally use this parameter when I tag my build in my source control management (SCM) and then use the tag value as the version. Of course, the version (SCM tag) is higher than the version deployed (which generally is an older SCM tag). This helps in co-relating what the version deployed to the version tagged in SCM.

Best Practices
Recall, a little above I stated that one of the requirements is that the version defined in the application descriptor is an integer. But then in the farVersion property I contradicted it by saying that you could pass in a string.
Well, let’s clear this up.

Development environment/cloud
Generally during development, you are building from HEAD (or TRUNK or MAIN branch) of your SCM and deploying to a development cloud. And during development you frequently build, deploy and test your changes. During this time, you don’t really care what the version is of the fabric/far as long as it is greater than the existing one so you can deploy it without Appistry CloudIQ baulking at your deploy attempts. Therefore during this time the “increment by 1″ strategy comes in handy. Hence it is a good practice to:

• Set the initial version in the fabric/far application descriptor to an integer, say 1
• Do not specify a farVersion property

and let the plugin do the job of updating the version every time you build.

Test or QA or Production environment/cloud
Once you are ready to deploy to a test/QA/production cloud, tag your code in SCM and use the tag as the value of the farVersion property. This way you know what version of code is deployed in your test/qa/production environments and you can reproduce those artifacts at will.

Origins…

maven-cloudiq-plugin currently started off as a simple way to integrate the creation of CloudIQ artifacts (fabric and far files) while building a Maven project on the Mac OS. As you may know, you create CloudIQ artifacts using fabric_pkg tool.

But, currently, there is no fabric_pkg for the Mac OS X. Therefore to create a fabric or far file you end up having to do the following:

1. SCP all your files – fabric/far resources, primary artifact (jar, war, etc.), dependent libraries, scripts, etc. – to a remote host that has Appistry CloudIQ installed
2. SSH to the above remote host and run fabric_pkg to create the fabric or far artifact
3. Deploy the fabric / far artifact to the cloud

Too time-consuming in my opinion! And you end up repeating these steps over and over again. DRY principle, anyone?

Heck if you are developing (on Windows or Linux) a Java application, installation package or service that get packaged as a Fabric or Far file and are using Maven as a build tool, to create the actual fabric or far file, you have to manually run fabric_pkg. Still a pain.

Since I use Maven a heck lot, I had to eliminate some of the repeated tasks. And thus the maven-cloudiq-plugin came forth. The primary objective of which was to integrate and make easy the building of CloudIQ artifacts while building a Maven project.

Looking forward…

Enough with the origins. What can we expect moving forward?

Although I won’t go into every single enhancement or new feature here (I haven’t thought about everything; that’s where you could contribute), I will list out some of the pressing issues that would greatly improve the usability of the plugin.

Some enhancements and features:

1. Auto-increment the fabric or far version in the application descriptors by looking up the latest version running in the cloud. Also, allow for manual override by user. Currently, the user has to update the application descriptors manually.
2. Auto-creation of Fabric and Far application descriptors. Currently, the user has to create these application descriptors by hand.
3. Auto-discover the appropriate CloudIQ artifact (.fabric or .far) that needs to be generated. Currently, the default is fabric. This is configurable though via the appExtension parameter.
4. Ability to deploy CloudIQ artifacts (and files) to clouds.
5. Ability to specify the list of dependent jars required at fabric package time. Currently, the entire kitchen sink of Maven dependencies get downloaded even though only a handful of jars gets included in the fabric file
6. Capture remote fabric_pkg output & error stream and log it out to the standard output during the Maven build.

So, above are some features/enhancements that need working on along with unit tests.

Interested enough to contribute?

If you are interested in contributing to the enhancements, features, and bug-fixes and making the maven-cloudiq-plugin robust and easy to use, feel free to clone the repository, send/attach code snippets, add additional enhancement/feature requests, etc.

Google Code and Mercurial
While I did not spend a ton of time evaluating a public project hosting provider, some of key things I was looking for in a project hosting provider was:

• Must provide DVCS (distributed version control system)
• Must provider some type of issue tracking system

Although GitHub and BitBucket seemed to fit the bill, I decided to go with Google code since it offers Mercurial DVCS (and Subversion as well). Mercurial (hg), IMHO, is faster and easier to learn than other DVCS. Again, this is purely my opinion.

Eclipse IDE has a nice plugin for hg. And NetBeans comes with support for hg out of the box.

How to contribute
If you are reading this post, I would encourage you to contribute to the development of maven-cloudiq-plugin. You can do so easily by cloning the project, fixing bugs, developing new features, requesting new features, and so on.

What is the purpose of the Appistry CloudIQ Maven plugin? See here

All Windows OSes with the exception of Windows 95 (I think) come with WSH pre-installed. And if you need it for Windows 95, you could download it from the Microsoft site.

To display the version of WSH installed on Windows, type cscript at the command prompt and then press ENTER. It should display an output like the following:

C:\Documents and Settings\xxxx>cscript
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Usage: CScript scriptname.extension [option...] [arguments...]

Options:
//B Batch mode: Suppresses script errors and prompts from displaying
//D Enable Active Debugging
…
…

To read more about WSH: http://www.microsoft.com/technet/scriptcenter/guide/sas_wsh_overview.mspx

Enough talk. Let’s see an example script that sets an environment variable (say, ”environSet.vbs”):

'Set JAVA_HOME, JRE_HOME and update PATH
set shellObj = WScript.CreateObject("WScript.Shell")
set envObj = shellObj.Environment("System")
envObj("JAVA_HOME")="C:\tools\jdk\jdk1.6.0_10"
envObj("JRE_HOME")="C:\tools\jdk\jdk1.6.0_10\jre"
envObj("PATH")=envObj("PATH") & ";%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin\client"

To run the above script, you can open a command shell, type cscript environSet.vbs (or just environSet.vbs) and press ENTER or just double-click the environSet.vbs file.

In the above example, the JAVA_HOME and JRE_HOME system environment variables are set to “c:\tools\jdk\jdk1.6.0_10″ and “c:\tools\jdk\jdk1.6.0_10\jre” respectively. The PATH system environment variable is updated and appended with “%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin\client”.

Notes:

• If the variables do not exist, they are created. If they already exist, they will be over-written unless you take care to append them as shown in the above example (see PATH)
• When you run the above script, the updates are also reflected in the registry. In the above case since we have set the System environment variables you could browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\ in regedit to see the system environment variables.
• Some pre-defined system variables such as PATH may not be picked by Windows services and will require a Windows Reboot.

Pre-requisites to running the code sample provided:

• JDK 1.5+
• Appistry EAF 3.8 Release
  
• Maven 2.0.7+.
  
• An IDE to write/edit code. I use Eclipse 3.3.2 and the code in the zip file has eclipse-related files. But you could easily download the code and use it with an IDE of your choice.
• m2eclipse plugin – maven integration for Eclipse. *This is optional*, but if you are using Eclipse as your IDE, I recommend using it.
  

Installing the above software
See here on how to install Appistry EAF 3.8 Release on Cent OS, RHEL, and SuSE.
See here on how to install Appistry EAF 3.8 Release on Cent OS, RHEL, and SuSE.

Installation instructions for Java, Maven and Eclipse are provided on their respective web sites.

Creating the Maven project
This example is based on the tutorial samples (spring_hello_world – see tutorial_samples.zip or tutorial_samples.tgz) provided on this page.
Allright, let’s get started by designing some components:

HelloWorldSpringService – interface that exposes a single “greet” method. Remember – program to interfaces!

HelloWorldSpringServiceBean – provides the implementation for HelloWorldSpringService.

HelloWorldSpringClient – client that calls the HelloWorldSpringService.greet method

Since HelloWorldSpringService interface is implemented by HelloWorldSpringServiceBean and is used by HelloWorldSpringClient, let’s put HelloWorldSpringService into a common module, say HelloWorldCommon.

HelloWorldSpringServiceBean could go into a HelloWorldService module while HelloWorldSpringClient could go into a HelloWorldClient module.The above structure provides a clean separation between the interface, implementation(s), and the client.Now that we have the structure laid out, let’s start by creating these maven modules. I’m not going to use the m2eclipse plugin to create a multi-module project in eclipse, but instead will use mvn from the command line to create the modules. You are free to use the m2eclipse plugin to create the project and modules. Usage of m2eclipse is beyond the scope of this article.First, let’s create a project, HelloWorldSpring, that will be the parent of HelloWorldCommon, HelloWorldService, and HelloWorldClient. Open a shell, change to your eclipse workspace directory, type in the following command and hit enter:

mvn archetype:create
-DgroupId=com.appistry.samples
-DartifactId=HelloWorldSpring

The above command will create a HelloWorldSpring maven project.
* Non m2eclipse plugin users: If you do not plan on using m2eclipse, from the command line change directory to HelloWorldSpring directory, type the following command and hit enter:

mvn eclipse:eclipse

Since we want this to be the parent project, go ahead and delete the “src” directory under HelloWorldSpring. Next, edit the HelloWorldSpring’s pom.xml – change the packaging element’s value from jar to pom.

Next we need to create the HelloWorldCommon, HelloWorldService, and HelloWorldClient modules. Go back to your command line, and change directory to <workspace>/HelloWorldSpring. Type the following commands and hit enter:

mvn archetype:create -DgroupId=com.appistry.samples -DartifactId=HelloWorldCommon
mvn archetype:create -DgroupId=com.appistry.samples -DartifactId=HelloWorldService
mvn archetype:create -DgroupId=com.appistry.samples -DartifactId=HelloWorldClient

The above 3 commands create the HelloWorldCommon, HelloWorldService, and HelloWorldClient modules under <workspace>/HelloWorldSpring directory.
* Non m2eclipse plugin users: If you do not plan on using m2eclipse, from the command line change directory to HelloWorldSpring directory, type the following command and hit enter:

mvn eclipse:eclipse

Next, fire up Eclipse and select the workspace that you created the above maven project under. Now, create a new Project by clicking “File -> New -> Project…”. Select “General -> Project” and hit “Next”. Type “HelloWorldSpring” for Project Name and click “Finish”.
You should see, a HelloWorldSpring project with HelloWorldCommon, HelloWorldService, and HelloWorldClient under it.
If you plan on using m2eclipse plugin, now would be a good time to right-click on the project and select “Maven -> Enable Dependency Management” and then right-click again on the project and select “Maven -> Enable Nested Modules”.
* Non m2eclipse plugin users: Right-click “java” (under HelloWorldSpring -> HelloWorldCommon -> src -> main), select “Build Path -> Use as Source Folder”. Do the same for “java” under HelloWorldSpring -> HelloWorldService -> src -> main and HelloWorldSpring -> HelloWorldClient -> src -> main.Now you have the HelloWorldSpring multi-module project configured under Eclipse! See Figure 1

Figure 1

Next we need to update the poms.

HelloWorldSpring pom.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<project xmlns=”http://maven.apache.org/POM/4.0.0″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd”>
<modelVersion>4.0.0</modelVersion>
<groupId>com.appistry.samples</groupId>
<artifactId>HelloWorldSpring</artifactId>
<packaging>pom</packaging>
<version>1.0.0-SNAPSHOT</version>
<name>HelloWorldSpring</name><properties>
<!– Default JDK Level –>
<jdkLevel>1.5</jdkLevel>
</properties><modules>
<module>HelloWorldService</module>
<module>HelloWorldClient</module>
<module>HelloWorldCommon</module>
</modules><dependencyManagement>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>HelloWorldCommon</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</dependencyManagement><dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.4</version>
<scope>test</scope>
</dependency>
</dependencies><build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<!–<version>2.0.2</version>–>
<executions>
<execution>
<id>compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>unit-test-compile</id>
<goals>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<configuration>
<source>${jdkLevel}</source>
<target>${jdkLevel}</target>
</configuration>
</plugin><plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.2</version>
<configuration>
<excludes>
<exclude>**/*$*</exclude>
</excludes>
</configuration>
</plugin><plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.0</version>
</plugin>
</plugins>
</pluginManagement>
</build>

</project>

HelloWorldService pom.xml
Add HelloWorldCommon dependency to HelloWorldService

<?xml version=”1.0″?>
<project>
<parent>
<artifactId>HelloWorldSpring</artifactId>
<groupId>com.appistry.samples</groupId>
<version>1.0.0-SNAPSHOT</version>
</parent> <modelVersion>4.0.0</modelVersion>
<artifactId>HelloWorldService</artifactId>
<name>HelloWorldService</name><dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>HelloWorldCommon</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</project>

HelloWorldClient pom.xml
Add HelloWorldCommon dependency to HelloWorldClient. You will also need to add Spring as a dependency. I’m using Spring 2.5.4.

<?xml version=”1.0″?>
<project>
<parent>
<artifactId>HelloWorldSpring</artifactId>
<groupId>com.appistry.samples</groupId>
<version>1.0.0-SNAPSHOT</version>
</parent><modelVersion>4.0.0</modelVersion>
<artifactId>HelloWorldClient</artifactId>
<name>HelloWorldClient</name><dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>HelloWorldCommon</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.4</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>
</project>

Now we are ready to code the HelloWorldSpringService, HelloWorldSpringServiceBean, and HelloWorldSpringClient.

HelloWorldSpringService
The HelloWorldSpringService has one method greet which takes a String parameter.

package com.appistry.samples.spring.helloworld;

public interface HelloWorldSpringService {
    String greet(String name);
}

This interface goes under the HelloWorldCommon module under HelloWorldCommon/src/main/java.

HelloWorldSpringServiceBean
The HelloWorldSpringServiceBean class implements HelloWorldSpringService interface. It goes under the HelloWorldService/src/main/java.

package com.appistry.samples.spring.helloworld.impl;

import com.appistry.samples.spring.helloworld.HelloWorldSpringService;

public class HelloWorldSpringServiceBean implements HelloWorldSpringService {

	public String greet(String name) {
		return "Hello World, " + name;
	}
}

HelloWorldSpringClient
Next, add the client that calls HelloWorldSpringService.greet. HelloWorldSpringClient class goes under HelloWorldClient/src/main/java.

package com.appistry.samples.spring.helloworld;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class HelloWorldSpringClient {

    public static void main(String[] args) {
	ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext("helloWorldClient-appContext.xml");

        HelloWorldSpringService localHWS = (HelloWorldSpringService) appContext.getBean("localHelloWorldBean");
System.out.println(localHWS.greet("locally."));

    }
}

helloWorldClient-appContext.xml is detailed below and it goes under HelloWorldClient/src/main/resources (add the “resources” directory under HelloWorldClient/src/main as a “source” folder in Eclipse):

<?xml version=”1.0″?>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN” “http://www.springframework.org/dtd/spring-beans.dtd”><beans>
<bean id=”localHelloWorldBean” class=”com.appistry.samples.spring.helloworld.impl.HelloWorldSpringServiceBean”/>
</beans>

Let’s package, install and run HelloWorldSpring. From the command, type the following command from under <workspace>/HelloWorldSpring to package and install HelloWorldSpring artifacts to your local maven repository.

mvn clean install

From Eclipse, run HelloWorldSpringClient as a Java Application. You should see an output like this:

…
…
Jun 20, 2008 4:35:26 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@18a7efd: defining beans [localHelloWorldBean,fabricHelloWorldBean,fabric]; root of factory hierarchy
Hello World, locally.

The HelloWorldSpringClient application loads the helloWorldClient-appContext.xml spring application context, gets a reference to the HelloWorldSpringServiceBean and calls the greet method on it. So far we have seen nothing with regards to the fabric/grid. If you would like to take a break, now would be a good time to do so. Go on. I’ll be right here.

Exposing the HelloWorldSpringServiceBean as a fabric bean
To expose our existing HelloWorldSpringServiceBean in the fabric, we need to package and deploy the HelloWorldSpringServiceBean into the fabric.
Let’s begin by first defining the HelloWorldSpringServiceBean in a spring application context (spring_hello_world_bean.xml).

<?xml version=”1.0″?>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN” “http://www.springframework.org/dtd/spring-beans.dtd”><beans>
<bean id=”HelloWorldBean” class=”com.appistry.samples.spring.helloworld.impl.HelloWorldSpringServiceBean”/>
</beans>

Place this file under HelloWorldService/src/main/resources
Note: Do we need to expose this in the fabric as a spring bean? No. We could have exposed it as a regular POJO. But the purpose of this example is to show Spring integration with Appistry EAF.
Now that we have wired the HelloWorldSpringServiceBean in a spring container, we need to define this bean as a Fabric Java Component. This is accomplished using the EAF Component Definition XML.

springHWSvc-component-defn.xml

<?xml version=”1.0″ encoding=”utf-8″?>
<java-components xmlns=”http://www.appistry.com/ns/component” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://www.appistry.com/ns/component eaf-component.xsd”><component name=”mvnSpringHWSvcComponent” default-timeout=”5″>
<spring-bean name=”HelloWorldBean”/>
</component>
</java-components>

where,
the name attribute of the spring-bean element should match the bean id defined in the spring_hello_world_bean.xml spring application context. In this case, HelloWorldBean.
The default-timeout specifies how long to wait for a call (to a method) to return before timing out. In this case, we have specified 5 seconds.

Place this file under HelloWorldService/src/main/scripts for now.

So how does the EAF tie the component definition file and the spring application context? This is done via the EAF Fabric Application Definition XML.The fabric application definition file describes the various files that comprise a EAF fabric application. This file is used by the Fabric Package (which we will encounter momentarily) to bundle these files into “.fabric” package.

springHWSvc-fabric-app-defn.xml

<?xml version=”1.0″?>
<!DOCTYPE app SYSTEM “FabricApp.dtd”><app name=”mvnSpringHelloWorldSvc” version=”1.0.0″>
<spring>
<bean-factory-locator bean=”myBeanFactory” resource-location=”beanRefFactory.xml”/>
</spring><components>
<file name=”springHWSvc-component-defn.xml”/>
</components><java-libs>
<file name=”HelloWorldCommon.jar”/>
<file name=”HelloWorldService.jar”/>
<file name=”spring.jar”/>
<file name=”commons-logging.jar”/>
</java-libs>
</app>

where,
components, file – is component definition file that we defined earlier
java-libs – dependant java libraries that will be included in the .fabric application.

Place this file under HelloWorldService/src/main/scripts

The interesting element in this file is the . The bean-factory-locator element provides the Fabric with an implementation of Spring BeanFactory to enable it to access spring bean containers / application contexts. The BeanFactory (provided to the Fabric) is itself described in a spring application context. In this case, beanRefFactory.xml.

beanRefFactory.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN” “http://www.springframework.org/dtd/spring-beans.dtd”><beans>
<bean id=”myBeanFactory” class=”org.springframework.context.support.ClassPathXmlApplicationContext”>
<constructor-arg value=”spring_hello_world_bean.xml”/>
</bean>
</beans>

The bean id in beanRefFactory.xml should match the “bean” attribute of bean-factory-locator in the fabric application definition xml. In this case, myBeanFactory.
In the above application context, we have configured the ClassPathXmlApplicationContext (a super set of the BeanFactory) and pass it the name of the application context, spring_hello_world_bean.xml, that contains our HelloWorldSpringServiceBean.

Place the beanRefFactory.xml under HelloWorldService/src/main/resources

Now we are ready to package our HelloWorldSpringServiceBean, so we can deploy it on the fabric. As you can see we have not modified the java code at all. All we have done so far is configure the HelloWorldSpringServiceBean POJO in a spring application context, describe the bean as a fabric Java component, and tie these elements (along with the BeanFactory) together using a fabric definition file. Non-intrusive, eh?

Build and Package HelloWorldSpringServiceBean
Packaging the application into .fabric file can be accomplished using the fabric pkg command. The fabric package command takes a fabric application definition file as input and bundles the application files into a single package (.fabric). We can configure the fabric package in the HelloWorldService pom.xml. But before we do this, we need to first download the dependant jars listed in the java-libs section of the fabric application definition xml (springHWSvc-fabric-app-defn.xml) to a particular directory. This can be defined in the HelloWorldService pom.xml as well. Add the following snippet (after the dependencies element and before the closing project tag) to the HelloWorldService pom.xml:

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<id>copy-required-dependencies</id>
<phase>install</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<stripVersion>true</stripVersion>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>HelloWorldCommon</artifactId>
<version>${project.version}</version>
</artifactItem>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
</artifactItem>
<artifactItem>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.4</version>
</artifactItem>
<artifactItem>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/fabric-package</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

This directs Maven (at install phase) to copy the HelloWorldCommon, HelloWorldService, spring and commons-logging jar files (with the versions stripped) from the local maven repository to the fabric-package directory under HelloWorldService/target directory. Since I’ve listed the jar files without version numbers in the element (in springHWSvc-fabric-app-defn.xml file), I tell Maven to strip the version numbers from the jar files while it’s performing the copy.

Now that we have addressed the jar dependencies, we are ready to configure the fabric_pkg command. Let’s configure the fabric package in ant build file target and call the ant build file from maven.
Note: You don’t have to necessarily configure the fabric_pkg in an ant build file. You could have configured it within the pom itself.

First let’s check out the ant build file.

build.xml (goes under HelloWorldService/src/main/scripts) – just displaying the necessary snippets. The attached HelloWorldSpring-source.zip contains all the source code listed here.

<!– copy the fabric application defn xml and component defn xml to fabric-package directory –>
<target name=”init”>
<copy todir=”target/fabric-package”>
<fileset dir=”src/main/scripts”>
<include name=”**/*-defn.xml”/>
</fileset>
</copy>
</target><!– execute fabric-pkg command –>
<target name=”fabric-package” depends=”init”>
<exec executable=”fabric_pkg”>
<arg line=”target/fabric-package/springHWSvc-fabric-app-defn.xml” />
</exec>
</target>

Now we need to update the HelloWorldService pom.xml to call the above ant build file. Add the following snippet (after the previous plugin definition and before the closing plugins tag) to the HelloWorldService pom.xml.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>fabric-package</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
<configuration>
<tasks>
<ant antfile=”src/main/scripts/build.xml” target=”fabric-package” />
</tasks>
</configuration>
</plugin>

Here we direct Maven (again, at install phase) to call the “fabric-package” target of build.xml. The fabric-package target first copies the springHWSvc-fabric-app-defn.xml and springHWSvc-component-defn.xml files to the HelloWorldService/target/fabric-package directory and then calls the fabric_pkg executable to bundle the application files into “mvnSpringHelloWorldSvc.fabric” file. You will notice that the name of the fabric file is the same as the name attribute of the app element in springHWSvc-fabric-app-defn.xml.

We are done with the package configuration. Now, open a command shell, change directory to /HelloWorldSpring, type the following command and hit enter:

mvn clean install

The above command will compile the sources, the application jars, install the application jars to the local maven repository on your local machine, and then create the mvnSpringHelloWorldSvc.fabric under the HelloWorldSpring/HelloWorldService directory.

Now you are ready to deploy the mvnSpringHelloWorldSvc.fabric to the EAF fabric.

Deploy HelloWorldSpringServiceBean
Let’s use the instructions detailed on the Appistry EAF wiki page – Building, Packaging, and Deploying a Fabric application. The fabric_ctl command can be used to deploy a fabric application.

To deploy the HelloWorldSpringServiceBean bundled in the mvnSpringHelloWorldSvc.fabric, type the following command (from under <workspace>/HelloWorldSpring/HelloWorldService) with the correct fabric adminstrative user, password, and fabric address. If you have stuck with the defaults, the command is:

fabric_ctl -d 239.255.0.1:30000 -u fabric-admin/fabric-admin deploy mvnSpringHelloWorldSvc.fabric

You can verify if the deployment is successful or not by following the instructions on this wiki page.

If the above command didn’t throw any errors, you have successfully deployed the HelloWorldSpringServiceBean, without any code changes, to the fabric.

Now that we have HelloWorldSpringServiceBean deployed to the fabric, how do we call the greet method on it from HelloWorldSpringClient?

Call HelloWorldSpringServiceBean remotely
Calling HelloWorldSpringServiceBean from HelloWorldSpringClient is achieved by a simple configuration in helloWorldClient-appContext.xml. And adding Appistry EAF provided fabric.jar as a dependency to the HelloWorldClient pom.xml

Since Appistry EAF fabric.jar is not available on a public maven repository as of yet, we need to install it to our local maven repository on our local machine. To do this, open a command shell, change directory to $FABRIC_HOME/classes, type the following command and hit enter:

mvn install:install-file -Dfile=fabric.jar -DgroupId=com.appistry -DartifactId=fabric -Dversion=3.8.0.15 -Dpackaging=jar

The above command will install fabric.jar to your local maven repository.

Next we need to add fabric.jar as a dependency to HelloWorldClient’s pom.xml:

<dependency>
<groupId>com.appistry</groupId>
<artifactId>fabric</artifactId>
<version>3.8.0.15</version>
</dependency>

Now we are ready to configure helloWorldClient-appContext.xml.
Append the following bean definitions to helloWorldClient-appContext.xml located under <workspace>/HelloWorldSpring/HelloWorldClient:

<bean id=”fabricHelloWorldBean” class=”com.appistry.spring.FabricProxyFactoryBean”>
<property name=”serviceInterface” value=”com.appistry.samples.spring.helloworld.HelloWorldSpringService”/>
<property name=”fabric”>
<ref local=”fabric”/>
</property>
<property name=”applicationName” value=”mvnSpringHelloWorldSvc”/>
<property name=”componentName” value=”mvnSpringHWSvcComponent”/>
</bean><bean id=”fabric” class=”com.appistry.fabric.Fabric”>
<constructor-arg value=”239.255.0.116″/>
<constructor-arg value=”31000″/>
</bean>

The bean fabricHelloWorldBean defines a com.appistry.spring.FabricProxyFactoryBean which proxies any calls made on HelloWorldSpringService to an instance of HelloWorldSpringService on the fabric. The concept behind FabricProxyFactoryBean is very similar to Spring Remoting. Infact FabricProxyFactoryBean uses Spring Remoting classes to proxy requests to the fabric.
The FabricProxyFactoryBean requires:

• the interface on which methods will be called,
• a reference to com.appistry.fabric.Fabric,
• an applicationName which should match the name attribute of the app element in the fabric application definition xml (springHWSvc-fabric-app-defn.xml),
• a componentName which should match the name attribute of the component element in the component definition xml (springHWSvc-component-defn.xml).

Let’s now add some code to HelloWorldSpringClient to call the fabricHelloWorldBean that we just defined above.

Let’s append the following two lines to the HelloWorldSpringClient’s main method:

HelloWorldSpringService fabricHWS = (HelloWorldSpringService) appContext.getBean("fabricHelloWorldBean");
System.out.println(fabricHWS.greet("from the fabric."));

Now we are ready to run HelloWorldSpringClient once again.

From Eclipse, run HelloWorldSpringClient as a Java Application. You should see an output like this:

…
…
Jun 20, 2008 4:35:26 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO:
Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@18a7efd:
defining beans [localHelloWorldBean,fabricHelloWorldBean,fabric]; root
of factory hierarchy
Hello World, locally.
Hello World, from the fabric.

The HelloWorldSpringClient application loads the helloWorldClient-appContext.xml spring application context, gets a reference to the fabricHelloWorldBean and calls the greet method on it. The FabricProxyFactoryBean proxies the greet request to the fabric. An instance of HelloWorldSpringServiceBean on the fabric executes the greet method and returns the results to the HelloWorldSpringClient which prints the result to the standard out.

As you can see, we haven’t changed any code on the client either. Just a little bit of configuration and that was it.

Download

Extract the contents of the zip into your eclipse workspace. This will create a HelloWorldSpring folder under your workspace.

HelloWorldSpring-source.zip

Appistry EAF Developer Portal

To learn more visit the Appistry EAF Developer Portal

I use Artifactory at my work place. And I’ve attempted using Archiva at home. But after installing Nexus, I prefer it over Artifactory and Archiva.

Here are a few reason why I prefer Nexus over Artifactory and Archiva:

1. I can control (add/update/remove) repositories via the UI without having to remote into my linux box and edit an xml file like I would have to do when using Artifactory.
2. Upgrading to a higher version of Nexus is simply a matter of unzipping the newer version, renaming the older version, and creating a soft link to the new version. I don’t have to bother exporting/importing data like in Artifactory.
3. The downloaded artifacts are stored on the file system (under $NEXUS_HOME/runtime/work/nexus/storage), and well organized into “repository-named folders” such as “central” (artifact downloaded from http://repo1.maven.org). I can now back up the “storage” directory easily.
4. Searching for artifacts using Nexus is fast. Searching with Artifactory was/is a pain – poor implementation of “google-like suggest” Ajax feature.
5. Installing Archiva to run as a war file in Tomcat is a pain. Archiva expects you to create an “archiva” folder under the $CATALINA_HOME directory. What the heck???? And the documentation seems lacking.
6. And oh, did I mention the slick UI ( Ext JS) that is provided by Nexus. It is far better than Artifactory, and Archiva!

Brian Fox, a committer of Nexus, discusses some architectural differences between Nexus and Artifactory here.

To be fair to Artifactory 2.x, here is a reply to the above post from the JFrog team, the creators of Artifactory.

You can change where Maven creates the repository. Open the settings.xml in your $M2_HOME/conf directory and change the localRepository element to point to the directory where you want Maven to download artifacts to.

That’s it!

What is Maven
Maven is more than a build tool. It’s is a project management tool. Maven’s power lies in it approach – standards over flexibility – and code reusability using plugins.

Maven Principles

• Convention over configuration
• Declarative execution
• Reuse of build logic
• Coherent organization of dependencies

Using standard conventions saves time, makes it easier to communicate to others, and allows you to create value in your applications faster with less effort.

There are three primary conventions that Maven employs to promote a standardized development environment:

• Standard directory layout for projects
• The concept of a single Maven project producing a single output
• Standard naming conventions

Why we are migrated to Maven from Ant builds
Using Ant we ran into the following issues:

• Lack of common approach OR copy, paste, edit approach
• A lot of time spent by developers configuring the build
• Any changes to project structure would mean changes to build and more configuration
• Configuring multi-module projects and dependencies were a huge task and required build expertise
• Not everyone knows how to write Ant build scripts

So despite creating and encapsulating the common tasks such as compile, compile-tests, run-tests, etc. into a build-common.xml Ant build file, it still wasn’t enough. By the way, in Maven, you don’t need to write common tasks as the above. All these come bundled via plugins in Maven. Behold the power of Maven plugins. Shout Hallelujah!

Maven can prove to be indispensable and IMHO, brings more value and speed than Ant when starting a new team and new projects. For example, one would not need to spend time creating, encapsulating, and testing the common tasks in a build-common.xml.

Of course, the previous statement/paragraph is not intended to downplay the benefits and value that Maven provides to projects migrating from Ant as you will see shortly.

Before we move on, it would be worth mentioning that “Standards over Flexibility” does not imply that Maven isn’t extensible. You may override some or all of the defaults – for example, you may choose to change the default directory names or change the default lifecycle – but it may prove to be counter productive and time-consuming in the long run. To quote Jerry Seinfeld,

“The road less traveled is less traveled for a reason”.

Maven Build Life Cycle

Every project follows a certain execution path or a process for building and distributing a particular artifact. Maven has standardized this process so that it is only necessary to learn a small set of commands to build any Maven project.

Lifecyle Phases – Description
validate – validate the project is correct and all necessary information is available
generate-sources – generate any source code for inclusion in compilation.
process-sources – process the source code, for example to filter any values.
generate-resources – generate resources for inclusion in the package.
process-resources – copy and process the resources into the destination directory, ready for packaging.
compile – compile the source code of the project.
process-classes – post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources – generate any test source code for inclusion in compilation.
process-test-sources – process the test source code, for example to filter any values.
generate-test-resources – create resources for testing.
process-test-resources – copy and process the resources into the test destination directory.
test-compile – compile the test source code into the test destination directory.
test – run tests using a suitable unit testing framework. should not require the code be packaged or deployed.
prepare-package – perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package – take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test – perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test – process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test – perform actions required after integration tests have been executed. This may including cleaning up the environment.
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.
clean – cleans up artifacts created by prior builds.
site – generates site documentation for this project.
How do you execute a certain lifecycle phase? By default this is specified in the POM. The “packaging” element in the POM defines the phase to execute and by default it is “jar”. So Maven will execute the above phases starting with validate up to and including packaging (jar). You can add extension points or customize your build lifecycle by configuring existing plugins or creating and adding your own plugin. You can also run a certain phase from the command line as:

mvn compile

The above will run all phases from validate up to and including the compile phase. A phase is a step in the build lifecycle. Phases are mapped to underlying goals. You can even execute a certain goal in a phase. For example,

mvn archetype:create -DgroupId=com.plexibus -DartifactId=com.plexibus.common

The above goal will create a directory with the same name given as the artifactId or in other words a new Java project with a standard structure as espoused by Maven. You can execute multiple phases as well:

mvn clean compile

Maven Standard Directory structure

Files – Description
src/main/java – Application/Library sources
src/main/resources – Application/Library resources
src/main/filters – Resource filter files
src/main/assembly – Assembly descriptors
src/main/config – Configuration files
src/test/java – Test sources
src/test/resources – Test resources
src/test/filters – Test resource filter files
LICENSE.txt – Project’s license
README.txt – Project’s readme
target – Generated output directory

Project Object Model

The POM is defined in a pom.xml file that contains all the information necessary to build the project, generate reports, and configure plugins. An example POM is show below:

	4.0.0
	for
	bar
jar
	1.0.0-SNAPSHOT
	bar
	
	
		
			junit
			junit
			4.4
			test
		
	

Maven model: http://maven.apache.org/ref/2.0.8/maven-model/maven.html
Maven Repositories
There are three types of Maven repositories

Local repository on the developer machine. This is usually located at ${user.dir}/.m2/repository
Shared internal repository or Corporate repository. Artifactory is a decent tool that can be used as a corporate repository
Public repository. By default you are pointed to http://repo1.maven.org/maven2. Although you can add additional repositories by configuring Maven (settings.xml), you should follow the standard operating practice that is point your Maven install to your organization's corporate Repository. Repositories are essentially directories with a certain structure.

Installing Maven

Download and install maven from here. Once you have installed it, add an environment variable
M2_HOME=<MAVEN_INSTALL_DIR>
Edit the settings.xml in $M2_HOME/conf to point to your organization's corporate Repository.
Maven frequently used commands
Create a new project
mvn archetype:create -DgroupId=foo -DartifactId=bar

or
mvn archetype:generate -DgroupId=foo -DartifactId=bar -B

or
mvn archetype:generate -DgroupId=foo -DartifactId=bar -Darchetype.interactive=false

Create a new web application project
mvn archetype:create -DgroupId=foo -DartifactId=barwebapp -DarchetypeArtifactId=maven-archetype-webapp

Clean up generated artifacts
mvn clean

Clean and compile the project
mvn clean compile

Clean, compile, and run unit tests
mvn clean compile test
Clean, compile and package to create an artifact (default jar)
mvn clean package
Clean, package up the artifact and install it into your local repository
mvn clean package install
Clean, package up the artifact and generate a website (documentation)
mvn clean package site
Generate Eclipse IDE settings
mvn eclipse:clean eclipse:eclipse -DdownloadSources=true
Creating a simple project in Maven
mvn archetype:create -DgroupId=foo -DartifactId=bar
Maven will create a directory with the name "bar". Change to the "bar" directory and you will see a generated pom.xml, and "src" directory with sub-directories such as "src/main", "src/main/java", "src/test", "src/test/java".
Multi-module project

Multi-module projects are slightly different in that each module (parent included) has a pom.xml.
Say you want a directory structure like:
bar

|-> baz

|-> bam
mvn archetype:create -DgroupId=foo -DartifactId=bar
This will create a "bar" sub-directory with a "pom.xml" and "src" sub-directory.

Change to the "bar" sub-directory and delete the "src" folder. Edit the pom.xml. Change the packaging element to "pom" instead of "jar".

Now from within the "bar" directory, execute the following command:
mvn archetype:create -DgroupId=bar -DartifactId=baz
mvn archetype:create -DgroupId=bar -DartifactId=bam

This will create the following modules (directories), "baz" and "bam" with their own pom.xml files and "src" sub-directories. You will also notice that the parent pom.xml (in "bar" directory) has been updated to reflect the child modules: "baz" and "bam".
You can now build "bar" which will in turn build the child modules "baz" and "bam"
mvn clean package
The parent pom (in bar) is inherited by the sub module poms. So you could effectively define global elements such as dependency like "junit" in the parent pom which will be inherited by the sub module poms. A good case for reuse and reduced redundancy. Defining the same element in the sub module will override the element definition in the parent module.
Maven and setting up Eclipse

Eclipse needs to know the path to the local maven repository. Therefore the classpath variable M2_REPO has to be set.

Select Window > Preferences. Select Java > Build Path > Classpath Variables.
Create a new M2_REPO variable and point it to your $\{user.dir\}/.m2/repository folder.
Next, from the menu bar, select Window > Preferences. Select the Run/Debug > String Substitution. Add a new variable e.g. maven_exec.
When you set up a new external launcher (from the menu bar, select Run > External Tools. Select Program) you can refer to maven_exec in the "Location" field. And add $\{project_loc\} to the "Working Directory" field. And then specify the maven goals of your choice in the arguments such as: clean package
You can set up multiple launch configurations such "clean, compile", "clean package site", "clean package install", etc.

Deploying artifacts to Corporate Repository
If you want to deploy a certain artifact or an artifact that isn't available yet in one of the public remote repositories, you can do the following:
mvn deploy:deploy-file -DrepositoryId=artifactory
-Durl=http://somerepository.com
-DgroupId=com.ibm.mq -DartifactId=com.ibm.mqjms -Dversion=5.3
-Dpackaging=jar -Dfile=com.ibm.mqjms.jar

*Note:* You should never have to use the deploy command since you should have your continuous integration tool deploy the artifacts to your organization's corporate repository.
Maven Global and User settings

Maven has two settings files, one in the Maven installation directory (under conf) - settings.xml (global settings), and one in the user's home directory. They are merged, and the latter overrides anything in the former. If you want to override the global settings you could pass an additional parameter (-Dorg.apache.maven.global-settings) when you run maven commands as follows:
mvn clean install -Dorg.apache.maven.global-settings=c:\new_global_settings.xml

Note that you are only overriding the global settings here. Therefore if you have a user settings xml, that will still be applied. The -D argument above is deprecated in 2.1.x. Use -gs instead.
mvn clean install -gs c:\new_global_settings.xml

If you want to override user settings, you could pass the new user settings as follows:
mvn clean install -s c:\new_user_settings.xml

Tagging, Branching, Releasing using Maven

Coming soon!
Troubleshooting tips
Maven help
mvn --help
OutOfMemoryError

If you are getting OutOfMemoryErrors when doing a build, try increasing the max heap and PermGen space sizes. You can do this by setting the MAVEN_OPTS variable
set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=256m
export MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=256m

Debug

The debug option is very useful when you find yourself in "classloader hell"(conflicting library versions or unwanted jars in your classpath). The debug option makes it easy to see where each library is coming from
mvn -X

Debugging test failures

Surefire, which is the default Maven test runner, outputs all reports as a set of xml and text files. Any test failure details and stacktraces end up in those files and not the console. The output can be redirected to the console temporarily by adding the following option
mvn -Dsurefire.useFile=false

Non-recursive option

Executing a Maven goal for a module will default execute the goal for any modules below it in the heirarchy. If you specifically wish to run the goal for this module only (and not it's children) you can use the non-recursive option:
mvn -N

Skip compiling unit tests
mvn -Dmaven.test.skip=true

Skip running unit tests
mvn -DskipTests

or you could set the skipTests property (maven-surefire-plugin configuration) to true in the pom
Ignore (do not fail) on test failures

This could be useful when you don't want builds to fail, such as clover builds.
mvn -Dmaven.test.failure.ignore=true

Generating clover reports without generating site

The following command will generate clover reports without generating the entire website.
mvn clover:instrument clover:clover

Move Local Maven Repository

See here on how to do this.
References

htt://maven.apache.org
]]>
			http://blogs.plexibus.com/2007/12/02/maven-guide-part-one-basics/feed/
		6
		
		
		
		http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/
		http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/#comments
		Thu, 22 Nov 2007 18:44:39 +0000
		roshanallan
				
		
		
		
		
		
		
		
		

		http://blogs.plexibus.com/?p=4
		
			I’m currently working on setting up and configuring the Maven release plugin on our projects for doing releases – primarily tagging, branching, and deploying a tagged release.

We have been using Maven extensively and I’ve been for the most part happy with it since we migrated from Ant. I say *most* since there have been a couple of times where Maven didn’t work as expected or documented. For example, in the current case, with the Maven release plugin.
Most of our projects are setup as multi-module projects with a parent pom and children jars. The Maven release plugin behaviour is suspect with multi-module projects.
For example, say I had project with “bar” as the parent and “baz”, “bam” and “dist” as the children modules. And “bam” has “baz” as a dependency. “dist” does the assembly using the Maven assembly plugin.
Running the following command on the “bar” tags the release fine:

mvn release:clean release:prepare

but fails during the following command which checks out the tagged release from our SCM and attempts to build it:

mvn release:perform
During release:perform, Maven first checks out the code using the above tag and then attempts to build (deploy goal) the checked out code (under bar/target/checkouts folder) using the command:



deploy --no-plugin-updates -P defaultRepo -DreleasePerform=true -f pom.xml



During the build, Maven attempts to download the release version of “baz” since it’s defined as a dependency in “bam” pom. Of course, this fails! Because “baz” isn’t available as a release yet.
After a “few gnashing of teeth and pulling of the hair” moments, I noticed that this is caused by the “-DreleasePerform=true” variable in the above command that Maven uses internally once I issued the “mvn release:perform” command. Take “-Drelease:perform=true” out, the release:perform works great.
To get past this issue, I had to override the default “preparationGoals” element of the Maven release plugin. The default preparationGoals are clean verify. Adding install after verify built the release jars during the release:prepare goal and installed it to my local Maven repository. So now when I run the  mvn release:perform command, it downloads the “baz” dependency from my local Maven repository.
A few other things I didn’t like:
1. Why can I not have 3rd party SNAPSHOTS in my release?

For example, one of our 3rd party dependencies is org.osgi.compendium, for which a release isn’t available. Apache Felix has only made it available as a SNAPSHOT. Having this SNAPSHOT as a dependency doesn’t go well with the Maven release plugin. It complains that there are SNAPSHOT dependencies and they need to be resolved to released. I know there are SNAPSHOT dependencies and I intentionally left them there since I don’t have *release* versions.

IMHO, there should be a setting to override this *Check that there are no SNAPSHOT dependencies* behavior.
2. Why doesn’t the Maven release plugin reuse the release.properties file that was generated during a dryRun when doing a release:prepare?

I like the concept of a dryRun when during a release:prepare. This gives me the opportunity to verify the changes that will be checked in to my SCM. Running the following command enables me to do this:



mvn release:clean release:prepare -DdryRun=true



The above command generates the temporary pom files and a release.properties file that I can scour through to make sure everything is correct.

Now one would assume that if you run the command:



mvn release:prepare



it would reuse the files that were generated by the previous command mvn release:clean release:prepare -DdryRun=true

But it does not!. Instead I am prompted to enter the release information again. What if I now mis-typed a letter??

Am I missing something here?
3. –batch-mode is only good if you want to stick with the versioning provided by the Maven release plugin. Why is customization not supported?

We version our projects as M.N.P

where,

M – Major release

N – minor release

P – patch or bug-fix release

The default versioning used by the Maven release plugin is M.N. Although I understand –batch-mode is provided to make our lives easier by going with the defaults, it doesn’t really. Since I’m stuck with the versioning standards provided by Maven. I like the “convention over configuration” approach. But by not allowing room for customization doesn’t help.
Apart from the above pain points, the Maven release plugin seems to do it’s job for us. We are planning on using it for now until something better comes up since it certainly bring some order to the chaotic world of tagging, branching and releasing.
]]>
			http://blogs.plexibus.com/2007/11/22/tagging-and-branching-with-the-maven-release-plugin-a-few-pain-points/feed/
		4