Implementing Maven in a Legacy Code Base

Posted on

It’s your first day with a new company or client. The usual things happen; you get introduced to everyone, shown where the toilets and fire stairs are located, pointed towards your desk, allocated a PC and login to the corporate network. Everything is going fine you login successfully, email works and you start to configure your PC to actually get some work done.

You install the Java IDE (in my case Eclipse) and get the URL for the source code repository. You check out the many modules that make up the application and start trawling through the code looking for hints on how the modules are built, pom.xml …, nowhere to be seen. Hmm, build.xml …, ah there you are, OK run the Ant build, FAIL, class not found, class not found…..

You look to the IDE for guidance, red crosses everywhere, same problem; there are multiple dependencies that are not in place (as far as the IDE is concerned). You figure I will discuss this with someone who is more familiar with the code base and application structure. What you find is that the application and module structure is tightly bound to that person’s IDE and is hidden within IDE metadata files. Worse still these metadata files are actually checked into the source code repository complete with hard coded locations to a particular person’s PC.

Sounds familiar? Dealing with a legacy code base that has grown over the years can be very difficult. In some instances the knowledge of the application is with one or two key staff members. Those people may have architected the application on the run and not followed industry standards. They may no longer be with the company. You’re left to work it all out, where do you start?

If you have a legacy code base that has multiple dependencies and is currently built via Ant, you can implement Maven within this code base. Here are some tips that may prove helpful.

1. Baseline

  • Get the application and all of its modules to a known working state.
  • Ensure that you understand the dependencies between modules and to 3rd party libraries.
  • Ensure that you can successfully build the application via the Ant build scripts.
  • Ensure that you can successfully deploy and run the application.

2. Create POM files for each Application Module

Create a pom.xml file for each of the dependent application modules. Ensure that it contains:

  • A &ltparent&gt section to provide the details of the parent POM.
  • A &ltrepository&gt section to provide the details of the enterprise remote repository.
  • A &ltdependency&gt section to provide the details of the installer provider. This will be required for step 3 (in my case I used wagon-webdav).
3. Deploy Application Modules to the Enterprise Remote Maven Repository

Modify the Ant build scripts of each of the dependant application modules to deploy the resulting artefact to the enterprise remote Maven repository. This can be achieved by using the Maven Ant Tasks (http://maven.apache.org/ant-tasks/index.html). The important points to remember are:

  • Ensure that you have a reference to the Maven-Ant task and that the file maven-ant-tasks-*.jar is on the classpath.
 <!-- Creates a classpath element for the Maven-Ant Task (http://maven.apache.org/ant-tasks/index.html) -->   <path id="maven.ant.class.path">        <fileset dir="${maven.ant.lib.dir}">             <include name="*.jar" />        </fileset>   </path>   <typedef resource="org/apache/maven/artifact/ant/antlib.xml"        uri="antlib:org.apache.maven.artifact.ant"        classpathref="maven.ant.class.path" />  
  • Create a classpath element that points to the dependencies within the pom.xml file create in step 2. This can then be used when compiling the code.
  •  <target name="initDependencies">        <artifact:dependencies pathId="maven.dependency.classpath">             <pom file="${project.dir}/pom.xml"/>        </artifact:dependencies>   </target>  
  • Create a deploy target that refers to the pom.xml file from step 2 and the correct enterprise remote repository for deploying artifacts.
  •  <target name="mvnDeploy">        <!-- Refer to the local pom file -->        <artifact:pom id="projectPom" file="${project.dir}/pom.xml" />        <!-- Defines the Remote Repository -->        <artifact:remoteRepository id="inHouseRepo" url="${maven.deploy.repository.url}">             <releases enabled="true"/>             <snapshots enabled="false"/>             <authentication username="${maven.deploy.repository.username}" password="${maven.deploy.repository.password}"/>        </artifact:remoteRepository>        <artifact:install-provider artifactId="wagon-webdav" version="1.0-beta-1"/>        <!-- Deploy the artifact using the new pom file to the Suncorp in house repository -->        <artifact:deploy file="${project.dist.dir}/${project.name}.jar">             <remoteRepository refid="inHouseRepo"/>             <pom refid="projectPom"/>        </artifact:deploy>   </target>  

    These application modules will now be stored in your enterprise remote Maven repository conveniently available for a Maven build.


    3. Create a Maven Project
    Depending on the architecture of your application you can either;

    • Create a new top level module as a Maven project
    • Convert the current top level module into a Maven project

    The key points with this activity are to;

    a. If you are converting ensure that you follow the directory structure require by Maven (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)

    b. Ensure that your new pom.xml contains all of the dependencies for the application. For the 3rd party libraries this should be a matter of digging through the various modules, finding the currently used 3rd party JAR files and adding entries to the pom.xml.

    For application modules create a entry for each module as follows:

     <dependency>   <groupId>com.company</groupId>   <artifactId>module-1</artifactId>   <version>1.0</version></dependency> 


    4. Test

    • Package the application via Maven (i.e. mvn clean package).
    • Inspect the resulting artefact.
    • Does it match the baseline artefact created successfully in step 1?
    • Does it run successfully?

    5. Repeat

    Now convert the next highest application module to a Maven project following the steps outlined above.

    Leave a Reply

    Your email address will not be published. Required fields are marked *