Bootstrap missing Maven project dependencies from source

From time to time one might face the problem that a required dependency for a Maven based project is not found in a public Maven repository, although it's source is accessible and it even turns out to be a maven based build. If you are fine with downloading the source, building and installing the needed artifacts into your local or company's repository, you are done quite easily. But what if you want to open your own project to a wider community, unable to share a common repository - how to produce a common, reproducible (kind of) and self-contained project build?

Here is where the bootstrap goal of the Maven scm plugin comes handy. It allows you to check out your dependency from source control and build and install it as a subtask of your own project build. If this is done before the main build's dependencies are resolved, you will get a nicely resolved self-contained build.

<dependencies>
    <dependency>
        <groupid>org.jboss.weld</groupid>
        <artifactid>weld-se</artifactid>
        <version>1.0.0-SNAPSHOT</version>
        <scope>test</scope>
    </dependency>
    ...
</dependencies>
<profiles>
    <profile>
        <id>bootstrap</id>
        <build>
            <plugins>
                <plugin>
                    <groupid>org.apache.maven.plugins</groupid>
                    <artifactid>maven-scm-plugin</artifactid>
                    <version>1.0</version>
                    <executions>
                        <execution>
                            <id>resolve-weld-se</id>
                            <phase>initialize</phase>
                            <goals>
                                <goal>bootstrap</goal>
                            </goals>
                            <configuration>
                                <goals>install</goals>
                                <connectionurl>scm:svn:http://anonsvn.jboss.org/repos/weld/java-se/trunk
                                </connectionurl>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile> 
</profiles>

This is an example for resolving JBoss Weld SE, the standalone version of the Weld CDI / JSR299 dependency injection container for JEE6, which I needed to build the Struts 2 CDI plugin. Currently it is not found in a public maven repo, while the source is freely available. Declaring this as a needed dependency would result in Maven not being able to resolve it in against any known repository, finally notifying you that you have to install it manually in your local repository.

But if you now - at least for the first time - call your build with mvn -P bootstrap <goal> to run with activated "bootstrap" profile, the project you depend on will be checked out from source, built and finally installed in your local maven repository during the initialize phase of your own project's build - et voilà, your project will now (hopefully) compile with nicely resolved dependencies.

Git-a-bit - How Git can be useful when being tied to Subversion

There's been a lot of talk lately about the new distributed version control systems like Mercurial, Bazaar or Git. It feels like just yesterday we started the fight to convince the world to switch from CVS to Subversion, and hopefully most of us won. But now more and more projects and even companies are switching to one of the new SCM systems, which might make one both consider why they do so and if one would have to undergo all that pain of convincing and migrating again if the concept looks appealing.

Distributed version control systems offer many advantages. They support offline working without the need of large feature cumulating commits when going back online again, which might be the first usecase people see and understand easily. But scratching the surface a bit, it reveals that there is a lot more, like ultra powerful (of course distributed) branching and merging facilities enabling new development team workflows such as continuous integration per developer/pair, enhanced environments for subteam or featureset driven branches, and a lot more.

Let's say you got intrigued by the features and the advanced workflows those new systems offer and you might have decided to give Git a try because you heard that your IDEA IDE now supports full Git integration, and you are convinced that Linus is a cool guy - what next? Move your or your companies' repositories to Git? Even more complicated, if you are a freelancer or consultant like I am, convince all your customers that this is the next cool thing and they have to switch immediately?

A scenario I recently experimented with came up when I was thinking about a feasible process to enable a local CI infrastructure for experimental changes on the Struts 2 codebase. While we have our central CI builds set up, they mostly make sense for features which are targeted for soon to integrate improvements, unless you are working on a fresh early branch like upcoming version 2.2. You would not want to push highly experimental code that might break builds for a longer time or even might never make it into a release to the upstream repository. Nevertheless, when your experiments turn out to be both stable and useful, you would want to push them as a whole to the main repository.

The solution I came up with was to use git-svn locally, which is not only able to make a git repository mirror out of a svn repo, but also to push changes back to the original svn repository. It helped me to introduce a very useful workflow, allowing me to commit small changes to my local git repository, triggering a local Hudson build, while I go over to the next change. I'm also able to pull incoming svn changes easily, improving the quality of the local integration test and solve merge issues upfront. After implementing and testing all changes, the commit to the svn repository then goes as a whole.

I started to build the Git mirror infrastructure from scratch, without knowing the concise Apache documentation on that topic which Don Brown pointed me to later. The only downside for my boilerplate solution was that since our svn tree is part of the huge Apache svn repository containing all revisions of all projects, the initial creation of the git-svn repo took about one (!!) day - it scanned about 7.3 million revisions only to get our "small" tree synced. But once done, things ran very fast, and getting the local infrastructure with Hudson and IDEA Git up and running was just peanuts.

After all, I found this workflow also very useful for my clients' projects, both for having a CI infrastructure set up even when the client refuses to and to have a good offline working infrastructure in place.