the bloggard

I first came across Maven a number of years ago at a client site we were doing some work at and got my hands dirty integrating it with a custom development project that was ongoing at the time and was very impressed with the efficiencies it brought to the project once some initial scripting was completed and the proper conventions were followed. At this stage, Maven 2.x was recently released and from all everything I read was a big improvement over the the earlier 1.x versions.

In the intervening years, my “usage” of Maven has been mainly around enforcing it’s adoption as the build and deployment tool of choice for a development team or recommending its usgae to other technical leads and architects. More recently however I was fortunate, or unfortunate as the case may be, to get my hands dirty with it again and integrate it with a Google App Engine project I was involved with. I was so moved by the experience that I am going to summarize my more recent experiences of it in this blog post …

For anyone not particularly familiar with it, Maven can be best described as a tool or xml based scripting language used to more effectively manage the artifacts typical of a software development project. These artifacts include project documentation, test reports, code coverage reports, and most importantly the artifacts that are the end result of the the build, deployment and release cycles. The closest analogy, which most people are familiar with, is that of the Apache Ant tool set. The two key differentiating factors between Ant and Maven are:

1. Where as Ant provides great flexibility with little or no constraints in terms of scripting the build and deployment processes, Maven favors convention over this, promising a minimal amount of work on the part of the developer assuming the standard conventions are followed.
2. Where as Ant is traditionally regarded as a build and deployment tool, Maven extends these processes, introducing the concept of build lifecycles and phases, and promises additional support for dependency management, documentation, reporting and release management. It should be noted that a combination of Ant and Ivy provide at least equal support for dependency management as Maven does.

The preceding image illustrates a good example of Maven convention, depicting the proposed folder structure for a standard Maven web application project. All source code and associated artifacts are stored in the “src” folder, with the “target” folder storing all the artifacts after the respective build lifecycle is complete. The “test” and “main” folders under “src” are used to distinguish test and standard code artifacts, with the subsequent “java”, “resoruces” and “webapp” folder containing java source code, property files and / or other resource files (e.g. xml files) and the web application skeleton for the project respectively.

I go to lengths to explain this as it really highlights the underlying tenet when using Maven. If this project structure convention is followed, it’s literally possible to have a web application project build and running with a servlet container such as Tomcat in a matter of minutes with NO additional scripting required. Compare this to any Ant based projects you may have worked on in the past where you’re typically scripting the compilation, test compilation, packaging and deployment steps in your Ant script. Maven eliminates all of this through the use of Maven plugins which are absolutely dependent on the project structure convention. This is a pretty powerful paradigm!

The downside to this of course is when you need to step outside of the boundaries of the conventions that Maven requires. And this is where the problems started for me recently. Having adopted Google App Engine as the platform of choice for a prototype application and Eclipse Ganymede as the IDE, a critical task underlying our Agile development model was the incorporation of an automated build and deployment system supporting iterative releases and continuous integration.

Why I Like Maven

Before discussing the issues encountered it’s worth mentioning why I like Maven so much and why I think it will win out over Ant + Ivy longer term:

1. Awesome dependency management directly integrated as a first part element of the toolset
2. The ubiquity and availability of plug-ins to support 95% of the tasks you want to do (e.g. test reports, war generation, tomcat container deployment & invocation), eliminating the amount of custom scripting required for a particular project
3. Extends the concept of build & deployment to include additional project lifecycles such as documentation management, continuous integration and release management, with existing plug-ins available to facilitate these extensions.

Challenges Encountered

As a somewhat early adopter of Google App Engine, it being in perennial beta at the time of writing, you’d expect some issues with the maturity of platform and the tools available but really hadn’t planned for some of the complications with getting the entire tool set to work together. The larger challenges dealt with are described:

1. Google Plugin for Eclipse does not play well with Maven – Google has an Eclipse plugin to aid with Google Web Toolkit and Google App Engine projects within Eclipse. This sounds great until you try and get it working with Maven. Unfortunately the Eclipse plugin breaks the conventions that Maven expects of a web application project in terms of directory structure and the build lifecycle. Specifically the plugin assumes a fixed war folder to store the web application, different from that expected by Maven. More details of the issue can be found at this link. NOTE: the latest release of the Google Eclipse Plugin, which I have not had the opportunity to test, has promised to resolve this issue.

2. Dependency Management is Mooted – The real power of dependency management comes from the ability to only need to declaratively specify what the organization who created the artifact, the name of the artifact and the version of the artifact you are dependent on and no more need be done e.g.

<!-- Test scope -->
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.5</version>
  <scope>test</scope>
</dependency>

This however assumes that the dependent artifacts are available in a Maven repository. Unfortunately this is not the case for any of the Google App Engine SDK libraries, GWT libraries or even the Google Data libraries. Consequently all the necessary Google dependencies needed to be manually installed to a local repository for them to play well with Maven. The overhead associated with this was mostly a once off to create and test the script to do this but would need to be rerun each time new library versions were to be used. Fortunately there is Maven plugin available for Google App Engine, maven-gae-plugin, which helps tremendously with the GAE libraries but this in itself was challenging to integrate given the infancy (version 0.5) of the version being used.

3. GAE SDK classpath issues – With the Google Eclipse plugin installed and running GAE development server from Maven after unpacking the SDK using the maven-gae-plugin numerous issues are encoutered due to classpath issues with the Maven generation of the classpath and the assumption of the Eclipse plugin of where the SDK resides. This was resolved by modifying the SDK location used by the eclipse plugin to point to the same one as was unpacked using the maven-gae-plugin. NOTE: the latest release of the Google Eclipse Plugin, which I have not had the opportunity to test, has promised to resolve this issue.

4. Superficial Maven integration with Eclipse – The m2eclipse plugin is the Eclipse plugin that is used to expose Maven functionality with Eclipse. However, the problem with the plugin is that it seems to be best at facilitating the ability to invoke Maven lifecycle and phases from the IDE there is no deeper integration that takes place. As such you essentially have the ability to execute all the command line functionality of Maven from within the IDE. This may sound appealing but in reality is only a smoke and mirrors effect as the power of the IDE is not being leveraged for features such as debugging, incremental compilation and packaging, which can save a development team lots of time over the course of a project. There is however an alternative eclipse plugin available, called Eclipse IAM, which promises to address some if not all of these issues, however I have not had the opportunity to try it out. My guess is that future versions of m2eclipse will provide a similar level of integration, if it doesn’t already, as it’s being maintained by one of the founders of the Maven project (if not the founder). The best strategy is to keep an the Maven Eclipse plugin page.

5. Maven / Eclispe / SVN mayhem – This situation, probably the most humorous of all the challenges faced, can be as much blamed on the persistence of the author to “get it right” as any shortcoming of a particular tool, leading to churn in the decision making process. When structuring a “multi-module” or “multi-component” project in terms of directory structure, looking at each of Maven, Eclipse, SVN in isolation likely leads to a predictable folder structure e.g. parent pom, sub-folder per module when using Maven, flat parent and and module project in Eclipse and something similar in SVN to support independent branching, tagging and versioing of parent project and modules in line with SVN best practices. The issue is that, using the m2eclipse plugin you can structure your maven project in line with the above and Eclipse will present it to you as a flat structure, nicely masking the true structure. The downside to this is that overlaying this with your SVN plugin in Eclipse and things start to go wrong. From there on trying to get things working as you’d like proved a fruitless exercise and was eventually abandoned (wisely) for a single project structure until such time as more flexibility is provided in these plug-ins. Lesson learned!

Summary

None of “challenges” described previously can be attributed to any one particular tool but combined they rather serve to highlight the types of challenge that will be faced as the diversity of tools on offer in software development are leveraged and combined in various ways .What started out as a desire to make things more efficient and flexible became a long and torturous road to get to point that was not 100% satisfactory and would likely require more maintenance over time as the maturity of some of the tools continued. Initially estimated at a 5 day task to get things running smoothly, the challenges effectively tripled the time it took to get the build and deployment processes working smoothly (I may write up the steps to get there in another post).

In hindsight, the only thing I would have done differently, would have been to abandon the use of Maven when it became obvious that Google through its Google App Engine, Google Web Toolkit and Google Data libraries showed no signs of familiarity with the Maven community and move to the flexibility of Ant + Ivy. This probably would have been more work initially but given the current state would be more effective over the medium term (6 months) until such as time as the issues mentioned above were resolved and usage was more widely adopted.

I continue to be a big fan of Maven and believe it is the tool of choice in custom development projects on a well established platform where effective dependency and release management and continuous integration are key to success. However, some challenges that Maven as a tool set needs to address before this might be considered a for gone conclusion are:

1. Steep learning curve – A huge advantage of Maven is that you can get a build and deployment process running with minimal knowledge based on the samples available online. The downside however is that if you need to do something non-standard or slightly different there is typically a huge learning curve to do what you need to, sometimes even for simple requirements.
2. Plugin Maintenance – The availability of plugins is a second huge advantage of using Maven. However it must be considered that for the most part these plugins are developed and maintained by third parties who have no obligation to continue to support them and will often have bugs in them also, causing pain at times and loss of productivity for a development team. In line with point 1, in this situation you will need to become an expert very quickly to overcome lack of support with a plugin or extend it to support a later version.
3. Improved IDE integration – Fortunately this is one area where work is actively being done to provide first class integration with a developers IDE.

In closing, these challenges described here should serve to highlight that if you plan to contribute to the development community, be familiar with your user base, and provide the necessary tools to allow the user base to be successful e.g. deploy your artifacts to centralized repositories and provide Maven plugins to ease the build and integration proces