Stefan Wagner

«Truth can only be found in one place: the code.»  Robert C. Martin alias Uncle Bob


Blog | Archive | Resume | Projects | References

Mavenize an Ant Application

02 Apr 2016 | maven, ant, svn, git

We’re changing our modularized application at work from building and deploying with Ant to Maven. The requirements to that process is:

The plan looks like this:

  1. create a branch in source control
  2. create new directories in src the maven standard src/main/java and add it to source control
  3. move all source files src/* to src/main/java/ and src/main/resources/ with source control not to lose any history
  4. create the pom.xml
  5. merge changes from colleagues to my branch
  6. at the end, merge my branch back to trunk

I wanted to be sure that I won’t have any disaster with the last steps to merge stuff together. I read about the weekness of svn in merging branches. And indeed, I tried it and run into merge problems.

So, what was needed is that I had to merge each module manually. Please!?!?

svn merge http://server/branch/module1/src/com src/main/java/
svn merge http://server/branch/module1/src/ src/main/resource/
svn merge http://server/branch/module1/test/com src/test/java/
svn merge http://server/branch/module1/src/ src/main/resource/
...

So I came up with the solution to use git on the client site. I got the code from the svn repository, which I kept synchronized with git master:

git svn clone file:///some/repo -T trunk -b branches -t tags

I did my work on a git branch and got the changes from my colleagues on git master once in a while. At the end I merge git branch with git master and with svn trunk. Gotya!

comments powered by Disqus

Older · View Archive (11)

Modularize a Grails application

I’ve just worked in a project where we upgraded a web application from grails 2.x to 3.x. One part of the application was divided into a plugin and three slim grails applications, which kinda inherited from this plugin. One of the grails applications was the official end user application and the other two where some kind of preview applications. We had some issues with this structure because plugins have the following disadvantage while development:

Newer

Automation, automation, automation ...

I’ve been hired to make some changes in an old J2EE application, which actually was very nice designed, state of the arte at its time but the company never updated the base technologies. It lied on EJB 2.1 with giant XML configuration files, Toplink ORM and Ant as the build system. The deployment was fully manual.