Migrating to maven

August 7, 2004

Category: Techy

Tags:

Just glancing http://www.onjava.com/pub/a/onjava/2004/08/04/maventips.html made me think of what I had gone through and how I would do the migration from Ant to Maven. Actually I was thinking of writing it, but I never got around to doing it and forgot about it.

  1. Create a new directory.
  2. Run maven genapp on the new directory to create the project descriptor and some other standard files.
  3. Modify the project.xml file so the sourceDirectory points to your existing source directory.
  4. Make a copy of your build.xml file and copy it to the new directory and rename it to maven.xml.
  5. Run the build2maven.xsl to transform maven.xml to a maven.xml file. (Too bad this does not exist yet so for now do the following…)
  6. Replace the project tag with something like project xmlns:j="jelly:core" xmlns:ant="jelly:ant" default="war" adjust the default accordingly.
  7. Replace the target tags with something like goal name="oldtargetname" prereqs="prereqtarget"/ adjust the name and prereqs accordingly.
  8. Test if everything still works, basically you’d have a drop in replacement where you just type maven intead of ant.

If you’re fortunate and everything work, you probably have a pretty simple build file or at least something easily transformable.

Once you get that done, the phase would be to migrate your dependencies to a more mavenized approach. Look for the dependencies that you have (usually a lib directory). You can do two approaches, one is to use the one in a maven repository (prefered) or just stick to the one in your lib directory. Whether you use the repository copy or your copy in lib, you have to add the dependency in your project.xml file. If you choose to use the lib directory then in your project.properties, add maven.jar.override=true and then put maven.jar.artifactId = ${basedir}/lib/foo.jar for each one you wish to use the lib version.

Once you do that modify your compile goal/target so you have the classpath looking like this

<ant:classpath>
  <ant:path refid="maven.dependency.classpath"/>
</ant:classpath>


Try to see if your build still works. Should be fine. This should be an easy enough transition.

I think now you can try to start using the java:compile goal. Then add maven.build.dest to the project.properties to make it point to your existing target directory. Run maven java to see if everything all compiles. Then you modify your maven.xml file to have [attainGoal goal="java:compile"] instead of [javac]

After you have done that, you can now relocate your code from your existing directory to the src/java directory in your maven project. This should not be too difficult assuming you got the java:compile thingy working.

The next thing you can do is to modify references to your compiled directory to use ${maven.build.dest} instead of what you currently have it coded to. Then take it off from your project.properties. Now your java sources and compiled code are now in the maven project.

If you have JUnit tests inside your source directory, you can move them out to src/test instead.

The only thing left to do is get your final targets out of your existing project directory to your mavenized project directory (this is not that trivial and would really vary from project to project). Just look at the jar, ejb, war, ear targets and see if you can just use them as is then you’re all done.

You can also try to get the other parts working such as the CVS repository so you can get statistics from your version control system.

Another way to integrate existing ant files

Instead of making a copy of the build file at first (which is a cut and paste anti-pattern) you can use the following method for each ant goal.

<project xmlns:ant="jelly:ant">
  <goal name="abc">
    <ant:ant dir="${basedir}" antfile="${nonmaven.dir}/build.xml" target="abc" />
  </goal>
</project>

Though I’d suggest you copy and paste stuff into the maven.xml file one section at a time while you are refactoring to maven instead of working on the original build.xml file so you do not affect your other developers who may still be using the ant method.


Now I am going through the article again and see how much mine matches. Um, totally different. Oh well to each his own methods. I’ll just comment on it anyway.