Can build management be made easier? Chances are whatever approach you take will have its own pitfalls and challenges. Many of the Java projects nowadays use Ant as the defacto build scripting tool. Its not too hard really. Can take a couple of days for a the Ant build file to be created (based on project needs). And subsequently it has to managed like any other source code. This approach works well. Most folks now know Ant well enough to get most tasks completed. Why then would anyone want to move to Maven!

Maven for starters makes it an easy task to manage your build file.Actually one step ahead … it makes it easy to handle your project artifacts (code, folder structure, normal build life-cycle tasks,documentation, etc). It also plugs in with many other open source tools to get the job done through Maven. Still why Maven. Take a look at Maven Getting Started.

Now you realize how simple things could be. One can argue that we have moved some of the complexity into the pom.xml file (the project object model). There will be a small learning curve (almost insignificant) in understanding how to use maven. Still nothing that Ant cannot do.

With Ant you have to write a lot of script lines to get most work done.In maven you use plugins that are built to do specific tasks. Plugins will do tasks like compile, clean, package to correct distribution(ear, jar, etc) and so on. Even has a command to build a project site.There are a lot of plugins available. For example check AppFuse for some of its Maven plugins that are coming soon.

The power of Maven is that you can accomplish a lot by reusing plugins and not having to roll your own script every time you need something new.

That to me personally is the single biggest reason to use Maven. And I have not even mentioned dependency management yet. A lot of projects do not really need the kind of dependency management that tools like Maven provide. Maven lovers please do not bash me for saying this . This feature can be really useful if your entire organization (or company)consolidates on using Maven or if you are on a project (or product development) where there is a high level of component reuse between developers and many of the components have multiple versions around.Developer A builds version 10 of a component and installs that into the Maven repository. Now others can use that as needed and still rely on the old version till they need to move ahead.

Still if you are using Maven on a regular web application project no harm in using its dependency management feature. Just remember to have a local repository on the network so that everyone can access the same repository and do check in the repository into your source control(subversion or cvs or whatever). Without Maven you would have co-located all of the libraries within your project folders and also checked them into source control. With Maven just because you have a central repository and no co-located libraries does not mean notchecking in the libraries (in this case the repository).

Some of the features I like in Maven (other than the standard build lifecycle ones):

• If you follow the default folder layout for the project type you are interested in then life becomes a lot more easier.
• Commands like mvn eclipse:eclipse that will generate IDE project files from your Maven project.
• Command mvn site will generate a project site.
• Managing resource files (like properties files). Maven does a nice job of organizing the folders for your resource files (both mainline code and test code separately) and optionally lets you do token filtering on those files.
• The many plugins available to create different types of projects. Plain vanilla java applications to web applications. Also there are plugins for many other often used tools such as cruisecontrol, clover, etc. Once project of that type is created you just run commands such as compile or package to get the job done.

One feature worth mentioning is how you can divide your project into separate projects (each with its own POM) and then have a top level Maven project (with its own pom.xml) that builds everything and merges dependencies between the two. Consider the scenario where you have a web application. You have all the web tier code (jsp, servlet, mvc,javascript, etc). You also have the service tier or the business tier.I would divide the two into separate independent projects, so that developers can work on them independently.

Here is how the directory structure looks like:

Now you can use the top level pom to build the whole project. You can set the web tier project to pull in the dependent libraries from the service tier project. Refer to the earlier link above to Maven quick start. They have a sample of how to configure this.

On a recent project we tried this exact same thing using Ant. The sub-projects would work just fine if you built them separately. If we used the top level Ant script we ran into some painful classpath issues. We gave up pretty soon as we were running out of time and in the end merged the two Ant files into one big one. Had we used Maven from day 1 we would have been in better shape. Which brings me to my final point. Try to use Maven from day 1. That way you can adhere to the folder structures that Maven generates by default. Retrofitting Maven into an existing project may not be a fun task. Also early on you will have to spend some extra time configuring Maven for the first time and generating a quick handy-dandy list of commands that developers(incl you) need on a daily basis.