Recently I joined a project with sources hosted on external Subversion server. Migration to Git is out of the question since the central repository is located in different country and used by many teams from departments spread all over this international corporation. Fortunately, there’s “git-svn” tool which can provide many great Git features. After setting it up I initialized my repo, downloaded the latest revision and launched Maven build. Surprisingly, it exploded with following error message:
The svn command failed.
svn: ‘.’ is not a working copy
[ERROR] BUILD ERROR
[INFO] Cannot get the revision information from the scm repository :
After quick investigation (mainly scouring through lenghty POM hierarchy) I found the culprit:
Maven Build Number plugin
This plugin gives many possibilities of generating build numbers as variables and then use them for any purpose. In my case, the plugin was included only to obtain the last svn revision number and store it in some variable. Then the value supposed to be put in .war Manifest file. Since I downloaded the sources via “git svn” there was no .svn directory anywhere and the plugin refused to work, so it terminated the whole build.
There are many options to avoid this problem, for example disabling the plugin in POM file or removing it entirely. Such methods are, however, too invasive and I didn’t want to mess with project configuration, even if it’s only on my machine. We all know that such “temporary” modifications are very likely to be eventually accidentally committed to central repo with painful consequences. Having that in mind, I went with another trick.
Silencing plugin from the inside
I downloaded source code of Maven Build Number plugin and erased most of it, leaving empty mojos with no bodies in execute() methods. Then I built it and replaced the original plugin in local maven repo with my “dummy”. Next, I launched the main project build and noticed no more svn errors. Everything went smoothly
The cost of my tinkering is of course invalid revision number in the Manifest file but I don’t believe it has any relevance for me during the development. Let the Continuous Integration server use it and save it, I am totally happy with my option.
There could be a distinction between different build types with possibility to switch them with Maven profiles. However, it adds some complexity for every person using the project, which I would like to avoid. I seem satisfied that the problem has been resolved quickly and without touching the project itself, so I can focus back on coding.