We’re going to use Maven

Well, we’re going to take a little longer to set up the project since we decided to use Maven !

Here are some words that Richard Allen posted on the Gwt-Platform group. This convinced us.

We have a large codebase with many projects that share a large amount of code housed in other projects. I used Ant for several years, but became frustrated with how much effort was required to maintain the whole build environment, and how I was regularly having to create custom solutions for things, like dependency management, that I felt should be the tool’s responsibility. I migrated all of our projects to Maven2 several years ago and have been very pleased. Maven is by no means perfect, so it will frustrate you at times. Maven lets you work at a higher level than Ant. Maven provides a lifecycle with phases such as compile, package, and integration-test, where as Ant provides low level tasks that you have to compose into the “phases” that Maven provides. Working at a higher level reduces your workload most of the time, but is a source of frustration when you need to work at a lower level. However, you can simply use the maven-antrun-plugin to run a set of Ant tasks when you want to work at a low level. And you can always write your own plugins to do anything you want. You can also write plugins in Groovy, which we have found to be easier. BTW, Maven3 is adding some nice scripting capabilities.

Maven has greatly reduced the overall maintenance of our build environment, as well as provided many features we didn’t have with Ant. Maven draws a lot of information from your POM files, and there’s much more to Maven than simply a build tool. Here are some of the benefits I believe you would derive from using Maven.

  • Very powerful dependency management. Maven makes it easy to handle your dependencies on third-party libraries, as well as dependencies on other projects that you maintain. Tools like m2eclipse and the maven-dependency-plugin, as well as the dependency reports generated by the maven-project-info-reports-plugin are invaluable when you want to see all your projects’ dependencies, their versions, and the licenses for your third-party dependencies. The dependency reports are great for open source projects because they provide your users (or potential users) an easy way to see what your project depends on while being very simple for you to produce and maintain.
  • Consistent project structure. Sure, you could devise your own project structure that you consistently used among all of your projects, but Maven already provides one that works well, and anyone that has used Maven before will immediately understand your project layout. Like I said, we have many projects, and it’s great that our developers can switch between projects without having to learn something new about the build environment. I love it when open source projects that I use also use Maven, because I can immediately build their project or import it into Eclipse. If they use Ant, it’s a toss up. Some are easy to build and import, others aren’t. There is no consistency.
  • Simple release management. I haven’t used Maven with Mercurial, but I see it supports it. Having used Maven with Subversion, I know Maven makes it very simple to make a release of your project and publish it to a Maven repository for public access, making your release process consistent and easy, as apposed to the error-prone process that many projects use. Maven’s release tools will ensure your code is committed to your source control and that your code passes all of its tests before making a release, and will automatically update the version numbers in the POM files for you. Additionally, you can create a report of changes from your source control system and/or a report of the fixed issues from your issue management system, like JIRA, that went into the release. This is where you start to see that Maven is a whole lot more than just a build tool.
  • Simple integration with unit testing tools and static analysis tools. Maven makes it easy to run your unit tests and integration tests, generate test coverage reports, run static analysis tools such as Checkstyle, PMD, FindBugs, JavaNCSS, and JDepend, and publish those reports to a website. These tools can be helpful to gage the overall quality of your code.
  • Simple reporting and website generation. I’ve already mentioned some Maven reporting capabilities, but Maven also has a general website generation tool. You can write a website in a wiki-like language and pull in all the reports that you generated. Some other reports that are important for projects to publish, which Maven makes easy, are Javadocs, browsable source code, and information on the project’s license, mailing list, source code repository, issue tracking system, the Maven plugins used for building the project, and the list developers.
  • Repository manager. The concept that Maven uses of storing dependencies and associated metadata in a repository instead of a source control system is a huge benefit. You can use a repository manager to cache all third-party dependencies that you get from the Internet to provide your group a stable repository, deploy your own projects (and custom
    Maven plugins) for other developers in your company to use, and even restrict what versions and libraries developers can pull into projects by making the build only get its dependencies from the repository manager.
  • Now, as for using Maven with Eclipse, you have three options. You can use one of two Eclipse plugins, m2eclipse or Eclipse IAM, or you can use the maven-eclipse-plugin to generate Eclipse projects. I have never used Eclipse IAM. My experience with m2eclipse is that it is nice for a small set of projects, but if you have a large multi-project structure like we do, then m2elipse consumes too much resources. So, I install m2eclipse for some of its tools, like seeing a hierarchy of the Maven dependencies for a project, and autocomplete while editing a POM file, but I do not import our projects as Maven projects into Eclipse. Instead, I use the maven-eclipse-plugin to generate all the Eclipse projects, and then I import them as existing Eclipse projects. We use a hierarchical structure for multiple projects, which is what Maven suggests, and so all I have to do is point Eclipse at the top directory and it will find all of the generated projects. The only primary drawback to this approach, as apposed to using m2eclipse, is that you have to re-generate your Eclipse projects if you add or remove a dependency. However, the process is very fast, and you simply have to refresh a project that you have already imported. Some day, I expect m2eclipse or Eclipse IAM to be efficient enough to just use them.

    Hope that helps.


That was a great and complete answer to our question and thanks to him, we finally made our mind !

Thanks Richard and everyone else that took the time to answer either here or on Gwt-Platform group.

  • I tried using Maven once and relied on the m2eclipse plugin. This turned out to be a very painful process and it made my Eclipse very unstable. I’m glad to hear about the maven-eclipse-plugin and will definitely consider using that.

    Please confirm: another benefit of the maven-eclipse-plugin seems to be that, if you generate the .project and commit it to source control, then users who don’t care about Maven can directly open your project into eclipse and compile it. Right/Wrong?

    • Richard Allen

      I’ll be happy when Maven integration with Eclipse is better. We also use Intellij IDEA and some have used NetBeans, and with those IDEs, the developers simply import the Maven POM projects directly. I believe, for the typical use case, the Maven integration with those IDEs is better. From what I’ve seen, the m2eclipse plugin provides more features, however, most users don’t need those extra features.

      I don’t believe you will be able to accomplish exactly what you are looking for by simply using the maven-eclipse-plugin.

      The maven-eclipse-plugin does generate the project files (.classpath, .project, etc), but the Eclipse project must have a reference to a local repository containing the dependencies (JARs). The local repository is simply a directory hierarchy containing the JARs and XML files that contain metadata about the JARs. The normal use-case is to add a Classpath Variable to Eclipse that points to your local repository directory, which is located at $HOME/.m2/repository (that location is configurable). The maven-eclipse-plugin will do this for you. The local repository is automatically created by Maven when you use Maven to build the project. Maven downloads (from remote repositories) all of the project dependencies (including Maven plugins being used) to that local repository, and then can be ran with no access to the network — what Maven calls offline mode. The .classpath file generated by the maven-eclipse-plugin has entries that identify the path to the location of JARs in your local repository.

      The Maven repository takes the place of you committing all your dependencies to source control (Mercurial in your case). The Maven repository is much more powerful than your source control system in terms of managing dependencies .

      Therefore, with 1) the Eclipse project generated by the maven-eclipse-plugin, 2) the Classpath Variable defined in Eclipse that points to your local repository, and 3) all the required dependencies in your local repository, then Eclipse has enough information to compile your Java code. So when I’m working in Eclipse using projects that I have generated using the maven-eclipse-plugin, I always have Eclipse compile the code to see if there are any errors.

      However, Eclipse does not have enough information to package your Java code into a deployable WAR. For example, straight Eclipse does not know how to run a GWT compilation. If you use Maven, then Maven is your build tool. The same applies if you use Ant, in particular if you use custom Ant tasks. You can execute Ant from Eclipse, but Ant is still the build tool. BTW, you can also execute Maven from Eclipse without using m2eclipse — simply define an External Tool Configuration.

      For third-parties to compile and package a project that you have created, they must use Maven. For example, the samples that you provide with gwt-platform use Ant to build them. I must use Ant to build them (or some other means, like the Google Plugin for Eclipse or Maven).

      • Thanks Richard, this is really useful information. My goal is twofold:
        1) Keep the barrier to entry as low as possible for new contributors on GWTP. i.e. I’d like them to be able to get the source, get the dependencies, launch eclipse, and start coding and compiling. Minimize the number of plugins or other tools required. I’m ok if they need maven to generate the jar.
        2) Make sure anybody can download and run the examples easily from source.

        From your answer, I tend to believe that both goals can be achieved. I think it should not be too hard to setup an automated process (in maven?) that packages the examples into a zip, including the required eclipse project files and all the dependencies.

  • Richard Allen

    The “barrier to entry” for using Maven is very low. The user needs an Internet connection for downloading artifacts from a remote repository, which they should already have if they are downloading the source code for your project. And the user needs to download Maven and extract the archive into a directory, just as they would if they were using Ant. Then they simply run the Maven executable on your project’s pom.xml (the same as running Ant on your project’s build.xml file). The user doesn’t have to know anything about the Maven plugins you are using because that information is defined in your project’s pom.xml files and Maven will download the plugins automatically. By default, Maven downloads dependencies from the Maven central repo, but you can configure custom repositories in your pom.xml files ( and ).

    Yes, you can create zips of anything you want to include using the maven-assembly-plugin. And you can publish this artifact to your own Maven repository for anyone to easily download, all done with an automated process. Again, this is where Maven shines as being much more than just a build tool.

    As I stated before, I prefer when projects use Maven, because I find it much easier to do exactly what you state, which is to get the source, build the code, and create a project in my IDE, so I can start playing with the code. And the reason for being able to get running faster when it’s a Maven project versus an Ant project has little to do with my knowledge of one versus the other. I used Ant for many years and know it well. Maven just provides an easier path.

    A neat feature that m2eclipse provides is the ability to create an Eclipse project from an artifact in a Maven repository. They call this ‘Materializing a Maven Project‘. If the project has the source control information in the pom.xml file, then m2eclipse will use that to get the source and create an Eclipse project. This is the fastest way to get running on an open source project that I have seen.

    BTW, if you haven’t found them already, the Sonatype books are a great resource for Maven information.