Incrementally Improving a Maven Build While Leaving the Existing Build Intact

April 16, 2009 By Jason van Zyl

4 minute read time

Today started out with completing the first version of the [Sonatype AppEngine Toolkit][sgt], deciding I wanted to push this code into [GIT][git] instead of [Subversion][svn] and then things just snowballed.

I wanted to try and use [JGIT][jgit] and the server code they have to host a repository that way instead of using the native version of GIT. I exchanged a couple emails with Shawn Pearce (very nice JGIT dude), looked around at a couple implementations ([Scumd][scumd] and [Gerrit][gerrit]) and then the fun began.

[hudson]: https://hudson.dev.java.net
[inst]: http://www.instantiations.com/
[kohsuke]: http://weblogs.java.net/blog/kohsuke/
[m2e]: http://m2eclipse.sonatype.org
[mark]: http://www.sonatype.com/people/author/mark/
[maven]: http://maven.apache.org
[nexus]: http://nexus.sonatype.org
[nxcm]: http://www.sonatype.com/nexus
[sat4j]: http://www.sat4j.org/
[sonatype]: http://www.sonatype.com
[webtide]: http://www.webtide.com
[wt]: http://www.instantiations.com/windowtester/index.html
[sgt]: https://issues.sonatype.org/browse/SGT
[atom]: http://www.sonatype.com/people/2009/04/how-to-convert-from-ant-to-maven-in-5-minutes/
[git]: http://git-scm.com/
[svn]: http://subversion.tigris.org/
[jgit]: http://www.eclipse.org/proposals/egit/
[scumd]: http://github.com/asynchrony/scumd/tree/master
[gerrit]: http://code.google.com/p/gerrit/
[sshd]: http://mina.apache.org/sshd/
[jpam]: http://jpam.sourceforge.net/
[issue]: https://issues.apache.org/jira/browse/DIRMINA-688
[jsw]: http://wrapper.tanukisoftware.org/doc/english/download.jsp
[jsecurity]: http://jsecurity.org
First I made a POM for the JGIT server code, it needed [Apache MINA SSHD][sshd] and so I checked that out and it didn't build because there were some dependencies missing in central. I looked at what was missing and noticed the build could be modularized a little better where some optional code for authentication should be pushed out into its own module. So I pushed [JPAM][jpam] 1.1 into Maven Central and created a separate module for it in SSHD. I also created a parent POM and a module for the core. Fixed the Spring test, and cleaned up the test dependencies (yes, if I use one of your projects you'll get a spruced up Maven build very quickly :-)).

So, to the point of the blog: how do you provide build changes like this that people can look at without changing an existing build? In very much the same way Brian describes in this [post][atom] where you create a script to provide the migration without touching the existing build. This is a great way to experiment and show people how directories can be structured, you can make new POMs and basically do whatever you want. So in my case I just posted a JIRA [issue][issue] with an archive containing the script and some new POMs. The script is really simple. It just creates a scratch directory, pushes new POMs in place, creates the modules, and moves some sources. So it's fully functional and if they want to take the changes they can just substitute in some svn cp/mv commands.

#!/bin/sh

dir=`pwd`/migration
rm -rf $dir
# Directories for new modules
mkdir -p $dir/sshd-core
mkdir -p $dir/sshd-pam
# Put the new POMs in place
cp sshd.pom $dir/pom.xml
cp sshd-core.pom $dir/sshd-core/pom.xml
cp sshd-pam.pom $dir/sshd-pam/pom.xml

# Copy source from original project structure to new project structure.
cp -r src $dir/sshd-core
(
cd $dir
# Take out code which is option and separate into its own module
mkdir -p sshd-pam/src/main/java/org/apache/sshd/server/pam
mv sshd-core/src/main/java/org/apache/sshd/server/pam/*.java sshd-pam/src/main/java/org/apache/sshd/server/pam
)

After a little trial and error, deploying a few artifacts to Maven Central we have a new working build that will function for people checking out from trunk.

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Apache Mina SSHD ...................................... SUCCESS [2.673s]
[INFO] Apache Mina SSHD :: Core .............................. SUCCESS [18.657s]
[INFO] Apache Mina SSHD :: PAM ............................... SUCCESS [0.701s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 22 seconds
[INFO] Finished at: Thu Apr 16 15:16:10 PDT 2009
[INFO] Final Memory: 12M/16M
[INFO] ------------------------------------------------------------------------

So now that's done I can go back to the [Sonatype AppEngine Toolkit][sgt] bits (though I'm still waiting for the Google folk to get back to me ;-)). Peter Royal (nice Mina/Apache dude) is going to help me this weekend with getting a stand-alone distribution of JGIT+Mina/SSHD working under the [Java Service Wrapper][jsw] with [JSecurity][jsecurity] wired in for authentication and authorization. This will be the start of Sonatype migrating wholesale away from Subversion to GIT. We'll also start using [Gerrit][gerrit] soon to try and make it easier for the community to contribute. I don't ever want to manually apply patches again.

Written by Jason van Zyl

Jason is a co-founder and the former CTO of Sonatype.

Explore All Posts by Jason van Zyl

Incrementally Improving a Maven Build While Leaving the Existing Build Intact

Get Sonatype Blog Digest