Mercurial (HG) Source Control with Maven

I've been using Mercurial for quite some time now. I've also been back up to my old tricks. On switching jobs a while back I came back into using Maven. I've also been hacking up some projects with pals and we host them on my site blueleftistconstructor. We found it would be easier to work on, distributed as we are, if we used Maven and created a Maven repository.

Well these projects are under Mercurial source control. I won't go to much into why I use Mercurial, especially why I use it over git, darcs and so forth. Lets just say I suits me and my partners.

So how easy is it to use Maven with Mercurial? Very easy it turns out. There was a little snag which I will get to later. First though you need to go get Mercurial. If you have a Mac you probably can just use easy_install, which is likely already installed. Try this:

easy_install mercurial

Using easy_install is my perferred method of installation. Otherwise download from the site.

Once you have verified Mercurial installed you just need to go into your projects root folder and type 'hg init' and you'll see Mercurial taking care of adding needed files. Now you will want to use the 'hg add' command to add files into source control. Read the docs for more information on how you can 'ignore' files.

Ok now we are ready to tell Maven that we are using HG to control. You will need to configure the scm section of your projects pom. It should look something like this:

<scm>
  <connection>scm:hg:https://www.blueleftistconstructor.com/hg/netflix-client</connection>
  <developerConnection>scm:hg:https://www.blueleftistconstructor.com/hg/netflix-client</developerConnection>
  <url>https://www.blueleftistconstructor.com/hg/netflix-client</url>
</scm>

Note that you will have to replace the URLs above with your own. The 'connection' URL is a public accessible URL, while 'developerConnection' is not going to be read only. The 'url' is a source control browser such as ViewVC or Fisheye.

Thats it. You now can use all sorts of Maven commands to manage source control actions. I myself don't often use these. The real benefit here is in releasing versions of your software. With the source control repo configured Maven takes care of committing, tagging, and rolling the version number up.

For more on releasing a Maven project that is configured for source control read this, and this.

Utilizing Maven Plugins: Jetty plugin

The problem: You would like to use a non-standard Maven plugin, such as the Jetty plugin.

The solution: First things first you will probably need to register the plugins group, so that Maven will know where to look. To do this you should put an entry in your settings.xml file. For our example here we will use the Jetty plugin. It has a group id of 'org.mortbay.jetty'. In your settings.xml file put an entry such as:

<pluginGroups>
  <pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>

What this little piece of configuration does is tell Maven to search for plugins registered under the given group id. You can have as many 'pluginGroup' elements in your xml file as you want/need. In all my work with Maven I have only actually registered two plugin groups, one of which is Jetty... but if you create your own you will need to register your plugin group.

Lets start by creating a web application using a Maven archetype:

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

This will create a folder called 'my-webapp'. Change over to this directory. Now we are going to use the long way of specifying the plugin. This is ugly and you certainly will not want to use this form often (likely ever).

mvn org.mortbay.jetty:maven-jetty-plugin:run

You should now be able to hit your web app on http://localhost:8080. The above command could be broken down as 'mvn groupId:artifactId:goal'. More on this in a bit. Now lets run the same 'run' goal using a short command syntax. Here is a simpler way to do the same thing:

mvn jetty:run

Much easier. Now I'll explain a bit. Since we put the plugin group entry in our settings.xml file we do not need to specify it like we did in the long command above. In the long command, after the group id, we have 'maven-jetty-plugin'. Maven expects the artifact id to be in a form 'maven--plugin'. For the Jetty plugin the artifact id is 'maven-jetty-plugin'. In the part after the colon in the long command we specify this artifact id. Now in the simple version we just have 'jetty'. Maven will take the 'jetty' value and automatically know to look for 'maven-jetty-plugin'. This saves you from typing out the whole shebang.

If your are interested in creating your own plugin I suggest you check this link out. It is not nearly as hard as you may imagine.

Going Offline

The problem: You want Maven to stop making all those network calls when you issue it commands like clean, build, test, package etc. You might want to work on a project while you have no network connection.

The solution: You can use the off line mode for Maven to keep it from making any network calls. You can do so by issuing the -o flag to the mvn command. When using this mode Maven will need to have all the jars it needs in your local repository (~/.m2/repository by default). To make this easier you can use a trick provided by the dependency plugin. Imagine we just checked out a project. Now we want to work on this project off line. To get all the dependencies needed by the project you can issue the command "mvn dependency:go-offline". This will download the dependencies you need. Now note it will not make sure you have all the plugins you need. Say you want to run "mvn -o site:run", creating a site for your project and making it available via Jetty. You will need to have used this plugin before so that it is in your local repo. The same goes for compile, package, test and the like.

The million dollar question is why use off line mode? Well it could be that it makes quicker the process you are doing with Maven, since Maven will not try to call out to any network repos. I've timed the difference between using it and not using it for some fairly large projects and found it doesn't make a huge difference. For really big projects (I cannot really name one) it might shed enough seconds to make it worth using often, maybe even creating an alias. This 'huge' project mind you would probably have upwards of 200 jar (dependencies) or more being managed. Another reason one might use off line is as follows: you have a local network repository used by the developers at work. One day the person you administers this repository is going to move it somewhere new. This going to take a few hours. Using off line mode you could weather this time if prepared without noticing too much that the repository is down. This could also be helpful in situations where you are going to not be able to reach the repository, like working at home with no network connection, or the server hosting the repo crashed.

Using Maven for Bash Script Projects

I recently created a Maven project unlike any I have ever created. This project contained no Java sources! No it was not a Groovy project ;) It was a project that contained only bash scripts. Read up for the why and the how.

I created a set of bash scripts that allow invoking SOAP services, returning the XML response. The SOAP services provide information on email distribution lists, such as which addresses are on a list and which lists a user's email address is subscribed to. These scripts are likely to change and grow over time so I made sure to put them into Subversion. Not too shabby. But what about distributing the scripts? What about managing versions of the scripts? I have become accustomed to having the aforementioned handled in my projects via Maven. Maven makes such things simple to set up and automate. I determined I could move these bash scripts into a Maven project to cultivate these benefits.

Now the how. For packaging I use the Maven assembly plugin. It allows created automated creation of zip tar.gz and gzip archives. These archives work great work distributing a project. I started my work by creating a skeleton Maven project. I put the scripts and related files into the src/main/scripts folder of the project. Next I created a xml file used by the assembly plugin to direct how files will be structured in the created compressed archive or archives. Here my file:

<?xml version="1.0"?>
<assembly>
    <id>zimbrascripts</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <dependencySets>
        <dependencySet>
            <outputDirectory>hacksdb/lib</outputDirectory>
        </dependencySet>
    </dependencySets>
    <fileSets>
        <fileSet>
            <directory>src/main/scriptapp/bin</directory>
            <outputDirectory>zimbrascripts/bin</outputDirectory>
            <fileMode>0755</fileMode>
            <directoryMode>0755</directoryMode>
        </fileSet>
        <fileSet>
            <directory>src/main/scriptapp/etc</directory>
            <outputDirectory>zimbrascripts/etc</outputDirectory>
            <fileMode>0644</fileMode>
            <directoryMode>0755</directoryMode>
        </fileSet>
        <fileSet>
            <directory>src/main/scriptapp/tokens</directory>
            <outputDirectory>zimbrascripts/tokens</outputDirectory>
            <fileMode>0600</fileMode>
            <directoryMode>0777</directoryMode>
        </fileSet>
        <fileSet>
            <directory>src/main/scriptapp/xml</directory>
            <outputDirectory>zimbrascripts/xml</outputDirectory>
            <fileMode>0644</fileMode>
            <directoryMode>0755</directoryMode>
        </fileSet>
    </fileSets>
    <files>
        <file>
            <source>src/main/scriptapp/README.txt</source>
            <outputDirectory>zimbrascripts</outputDirectory>
        </file>
    </files>
</assembly>

I'll write up a more thorough article on using the assembly plugin later. For now suffice to say this file will instruct Maven to create a zip archive containing the files listed above. The last thing we want to do is configure the assembly plugin in the project's POM file. I used the following XML in my projects pom:

<build>
  <plugins>
    <plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <configuration>
        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
        </descriptors>
      </configuration>
      <executions>
        <execution>
          <id>make</id>
          <phase>package</phase>
          <goals>
            <goal>assembly</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

In the above config I also bind the assembly goal to the package phase. This means when I execute "mvn package" the assembly plugin will fire off and create the zip archive. Nice! Otherwise you can also use "mvn assembly:assembly" should do the job. Now so that I could use the scm and release plugins to check in changes to SVN and create tagged releases of the project I added the following to the POM:

<scm>
  <connection>scm:svn:https://svn.com/DistributionLists/DistListScriptsMaven/trunk/</connection>
  <developerConnection>scm:svn:https://svn.com/DistributionLists/DistListScriptsMaven/trunk/</developerConnection>
  <url>https://svn.com/DistributionLists/DistListScriptsMaven/</url>
</scm>

Now to release the current version of the project I can type "mvn release:prepare". This will tag the current version in SVN, then update the POM to the new version number and check those changes into the SVN trunk. This saves me the hassle and reduces the chances of user error in this boring, repetitive process. In the vein of the SCM configuration you could now use other plugins such as the JIRA reporting plugin, site plugin etc. to bolster this simple bash script project.

Big Project Troubleshooting Pt. 1: Transitive Dependencies

Maven is complex, but so is Ant or Make once a project passes a certain size. With Maven many things are done in a standard way, so that when a project becomes large you still should be able to work with it easily. With Ant or Make a large project will likely have many arbitrarily named targets which you will have to study and learn. With Maven all those named targets are pretty much standardized by the plugins which provide all functionality. Large projects in Maven commonly have the same sorts of issues. These can be pretty nasty to for the uninitiated. So to help you out I'm going to write a series of articles tackling the problems faced in big Maven projects. In this article I'm going to give you some information on issues related to dependencies.

The dependency mechanism is the main reason many people become interested in Maven. It sure makes life easy... but everything cannot always be automated. Sometimes you will need to give Maven some help. It will try to correctly resolve the dependencies needed by your project by creating a graph. More on this in a second.

Maven has what is called a 'transitive dependency'. Let me explain transitive dependencies for those who don't know. A dependency of a project is defined via a project's pom.xml. Every dependency has a pom.xml (in the repository with the dependency) which is used by Maven to find the dependencies relied upon by a dependency. These 'relied upon' dependencies are also known as transitive dependencies. They are included into your projects class path automatically. Now you can have any number of levels of transitive dependencies because Maven also will get the each transitive dependency's dependencies. In Maven this forms what is called the dependency graph. Yes this is the same graph I spoke of earlier. It looks like a tree, with your project as the root node, tree level one as the dependencies of your project and subsequent levels being transitive dependencies.

Now lets talk about the sticky points. If there are two or more versions of the same dependency in the graph of the dependencies for your project then Maven will need to make a choice as to which one to use. By default Maven will use the version that is the closest to the top node of the tree. If this version is older than the other version(s) you may have a problem. Likely a NoClassDef where a class from the new dependency cannot be found, because it does not exist in the older version. When you get this error it should be obvious which dependency the error is being caused by. The stack trace should give the full package path to the class. We can use this to figure out how to fix the problem.

At this time you probably could open a terminal session and cd to your local repository location (~/.m2/repository by default) and then cd into the dependency's folder in the repository. This can be helpful since it will allow you to see which versions of the dependency are being used and which classes are in each dependency. You could execute a "jar -tf {jarname} | grep {ClassName}" command on each jar to search it for the given class.

Let us discuss troubleshooting. First you will want to run the mvn dependency:resolve command. This will print out a listing of the resolved dependencies for your project. Resolved dependencies are those calculated by Maven via the dependency graph to be used in the project. You should be able to see which version of the troubled dependency is being used. I had you cd to the dependencies repo location. Check now which versions you have in your repository. You should be able to use the "jar -tf " command to check if the class causing the NoClassDef exists in one of the newer version jars (if you have newer version jars). Once you have found a jar that contains the class make note of the version.

Now for some debugging. This is where you get waist deep in it. We are going to use the -X option to Maven, which enables debugging. We also want to run just the compile phase which will give us all the info we need on the dependency graph. You might want to do something like "mvn -X compiler:compile > junk.txt" just so that you can use a text editor like Vi to search about the file. Now when you view this output you will be able to find a listing of the absolute classpath, including with jars are being used. You also will get a printout of the dependency graph including info on what ended up making it in. It is pretty easy to find the version of a dependency being used: find the one with the least amount of indent. If one or more versions share the least amount of indent then the newest version will be selected.

To get around version problems you can do a number of things. The easiest thing to do is define the newer version of the dependency directly in the pom.xml of the project. This will make sure that the newer version is used because it is 1) at the top of the dependency tree 2) the version is highest. You can also use excludes for a dependency definition in the pom.xml file for the old version of the dependency. Since the old version is excluded the newer (yet further down the graph) version will be used. When using excludes you will need to figure out which dependency in the pom.xml file has the transitive dependency to be excluded. Neither of these fixes are tough to perform, and will become easy to do in time.

Maven Theory: Archetypes

Maven is a complex system to swallow in its entirety. Most persons first encounter it because they want to wield the dependency magic it offers. These persons are not savvy to the notion of repositories and with them the administrative work required to build and manage them. They are not likely to understand that Maven can build complex websites, containing useful reports on project health, with little configuration and user effort. These are things that Maven accomplishes in a very elegant manor (in my opinion). You see Maven 2 was built almost from scratch, using the knowledge gained in the creation of the original Maven. Hence a sound architecture was built in Maven 2 that has proven adaptable to many tasks.

In this post I want to talk more about one of the extension points of Maven 2. Archetypes. These are a lot like templates. When invoked an archetype will either create a new project, or add to an existing one. Archetypes can be created by an end user and deployed into a repository. This allows others to access the archetype and reuse it. A little while back I was doing a fair bit of SOAP service programming. I was using XFire in the creation of these projects, along with other Java technologies. After the first couple projects I decided creating an archetype for XFire projects would be handy. So I created an archetype project that could generate a bare bones Maven 2 project. This project would contain a pom with all the needed dependencies, and a simple "Hello World" SOAP service and an integration test. Now whenever I wanted to create a new XFire project I would just invoke this archetype; giving me a good head start! Now I would like to point out that, if you are like me, you would normally just find the 'similar' project then copy and paste. Then you trim down the copy or whatever. That is a viable alternative, although I feel one is better off with a nearly clean canvas when striking out on a project.

So now that I have talked your ear off, let me give an example of using a real archetype to generate a full project. The base Maven has an archetype for creating Maven projects. Seems reasonable eh? So to create your next computational masterpiece start with the command:

mvn archetype:create -DgroupId=com.someguy -DartifactId=masterpiece

And tadah you now have a folder called 'masterpiece' which contains a very basic Maven 2 project. There are other archetypes you can run with out any special setup, including an archetype to create archtypes! Now I'm not advocating creating an archetype as a precursor to any new project. Create one whenever you start to notice a pattern between projects. A good candidate for me was Spring, Hibernate and other dependencies I used very often in web projects. I created a simple archetype to create a bare bones web MVC application using these dependencies. With this I could start creating the controllers and .jsp pages in my application right away, rather than mucking around copying some old ant project :)

I will write up some better examples on archetypes down the road. I would like to give an example of creating a simple archetype. Keep tuned in for more, and do not hesitate to leave a comment or contact with ideas.

Import Maven Project into Eclipse w/ Style (Maven + Eclipse pt. 3)

The problem:

You have a Maven 2 project, and would like to work on it in Eclipse. Oh, and you want the Maven plug in for Eclipse configured on this project too!

The solution:

The first thing I do when I check out a Maven project is generate the Eclipse project files. Start by going to the project's root folder and typing:

mvn eclipse:eclipse

This will create the files Eclipse uses to understand the project, .project and .classpath. There are links to the jars configured via the pom in the .classpath file. You will want to get rid of these, because the Maven plug in will handle dependency configuration. Go into the .classpath file and delete all "classpathentry" nodes that have "M2_REPO" in the path attribute value. Now save this file.

At this point your project should have errors. Eclipse cannot find the jars needed to build properly. Worry not. Now we will enable the Maven plug in. Right click on the project root node in the package explorer to bring up the menu. Select "Maven" and then "enable". After a bit of processing your project should rebuild. Now you have the benefits of the Maven plug in!

Generate Website and View It Locally

The problem:

You are using Maven to create documentation on your project. You want to use the site plug in to generate this documentation into a website. What you need is a quick way to proof your changes, seeing how they look on the website.

The solution:

This one blew me away. When you are working on your documentation you can easily view changes, just run this command:

mvn site:run

This will get a Jetty web server going with your web site running on it. Now just go to localhost:8080 to see your site. This technique is really helpful when configuring reports, as you can quickly test them out.

If a project is configured with the Javadoc report there are some nice uses here. you can pop up a site while working on a project and view the Javadoc. This is a useful technique when first checking out a project, so that you may better familiarize yourself with it.

Release Plugin "Dry Run"

The problem:

Running the "release:prepare" command in Maven does a number of caustic things. It will check in and tag your code in the SCM you use. It will also change the projects pom, rolling the version number up. If you have any "SNAPSHOT" dependencies it will fail.

The solution:

Maybe you want to do a "dry run" before executing a command that could muck up your SCM and pom? By "dry run" I mean the release plug in goes through the motions, but nothing is changed in the SCM, and your pom doesn't get messed up. Here is what you do:

mvn release:prepare -DdryRun

The "-DdryRun" tells the plug in to not fully perform the preparation. You will find this generates some temporary files in the project folder. These include:

• pom.xml.next : what the projects pom looks like after the release
• pom.xml.releaseBackup : what the pom looked like before
• pom.xml.tag : the pom for the tagged version of project
• release.properties : the information about the release of the project

It is not likely you want to keep these files around for too long. You can remove these file by running this command:

mvn release:clean

I recommend you use this whenever you are getting ready to release. It will save you a lot of time, because just one botched release attempt could take minutes to clean up. The dry run will take seconds to run.

Release plugin

The problem:

Your project uses some sort of Source Control Management (SCM). Being that your project is using Maven there are considerations such as project version to take into account when tagging releases of your project. You want a simple way to "release" a version of your project. Normally you would edit the POM changing to a new release version (from snapshot), then tag the release in your SCM, then change the pom version to the newest version, and finally check in the new pom. Another consideration is the dependencies you are using, you do not want to have snapshot dependencies in your "released" project.

The solution:

Maven developers quickly experienced the difficulty of rolling a version of a project. Thats why we now have the release plug in. When you are ready to do a release simply issue the command:

mvn release:prepare

This plug in makes short work to releasing a version of your project. You must have configured the SCM section of the pom. This section is used by the release plugin to know how to interact with your SCM.

Once you issue the command above you will be asked to give a tag name and the new version for the pom. You can also just hit enter to have the plug in use default values. Thats it, check your pom and you will see the new version. Check the source control and you will see the tag.

Maven Plugin for Generating Eclipse projects (Maven + Eclipse Pt. 1)

The problem:

You want to use the ubiquitous IDE, Eclipse, with your Maven project.

The solution:

Just because you use Maven doesn't mean that you are going to jump through hoops to make it work with Eclipse; all you need to do is type "mvn eclipse:eclipse". This command will generate the .classpath and .project files that Eclipse needs so that it can understand your project.

Once you run this command in your project boot up Eclipse and click File -> import -> General -> Existing projects into workspace -> next, now use the enabled browse button to find the project's root directory. Once you do this click OK. You should see your project in the projects window. Make sure it is selected and press the "Finish" button.

Right now you probably see all sorts of errors. LOL. One last thing. You must create an Eclipse classpath variable that points to your local Maven repository. Click the following: "Window -> Preferences... -> Java -> Build Path -> Classpath Variables". You now shall click "new" button and create a variable with name "M2_REPO" and value being where your local Maven repo is found. Usually this is ${HOME_DIR}/.m2/repository. On my OS X machine this is "/Users/ottaway/.m2/repository". On my Windows machine it is "C:\Documents and Settings\rob\.m2\repository". Once you set this press the "OK" button.

Your projects dependencies should now be loaded. Note that if you add new dependencies to your project you will need to run the "mvn eclipse:eclipse" command again. This will regenerate the .classpath file that contains the dependencies.