Configuring Plugins
The top-level POM file (Listing Three) specifies a <plugin> element that configures the compiler plugin to use Java 1.5 source compatibility. The default is 1.3 for backward compatibility reasons. This mechanism allows configuring any plugin (builtin or custom) in a simple and consistent way. just add more plugin elements, identify them by group and artifact id and add the information to the <configuration> element of each plugin.
Maven's built-in plugins are not the end of the road. Many interesting plugins are available from different sources. I show you how to use the Tomcat plugin from codehaus. The Tomcat plugin resides in the Subversion repository of the codehaus. You need to install Subversion, get the source of the plugin build it and install it into your Maven's plugin repository.
Use this command to get the source:
svn checkout https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/tomcat-maven-plugin tomcat-maven-plugin
Once you got the source just go to the tomcat-maven-plugin directory and enter:
mvn install
The plugin will be installed and as long Tomcat is installed properly can deploy your app by typing:
mvn deploy
The tomcat plugin offers many goals for managing the Tomcat server: start, stop, list, info, and so on. Using the plugin require a special
Maven Versus Ant
Maven is the evolutionary successor of Ant. You can directly execute ant tasks in Maven (through a plugin of course), so Maven is a superset. However, this is not the whole story. The conceptual model is different. Ant is all about total freedom, which is not always good. Maven gives structure, advises on best practices and tries to solve some thorny problems like dependency management and shared artifacts in a neat way. If your project build deviates from Maven so much that it's easier to do it in Ant, I recommend you take a serious look and figure out why. Ant has the advantage of being mature, familiar and better documented. All are fleeting advantages and I belive Maven will gain more market share as time goes by.
Maven 1.x Versus Maven 2.x
Maven 2 is a radical departure from Maven 1. A lot has changed and many people belive non-compatible Maven 2 will hurt Maven's adoption in the short range. I agree, but I still think it's better in the long run. Maven 2 introduced hierarchical repositories. you can rely on some structure and organization in order to find something instead of plowing through a huge flat list of artifact directories. Maven 1 didn't have transitive dependencies, so you had to specify in every project all the dependencies of this project and all its dependencies' dependencies ad infinitum. Every dependency change in a POM down the line required fixing the POMs of all the projects that depend on it directly or indirectly. It becomes a maintenance problem pretty soon in big projects. Maven 1 didn't have the notion of scoped dependencies so you ended up either deploying junit and various jars provided by the web container or had to hack around your maven.xml file. Maven 1 plugins where mostly developed using Jelly—an XML-eque scripting language. It wasn't the best vehicle for developing plugins. Maven 2 plugins are developed using Java.
IDE Support
There is rudimentary support only for Maven 2. There are plugins for popular IDEs like Eclipse, NetBeans, IDEA, and JBuilder. They mostly let you generate IDE projects from POMs and edit the POM in the IDE instead of in raw XML.
bTroubleshooting Build Problems
Builds go wrong. Especially, when create a new build system or change something major (for instance, add a new type of artifact or life cycle phase). This is one of the weak points of Maven (and any other build system out there with the possible exception of SCons). There is very little material on the web on troubleshooting build problems. Maven's -e and -X flags are your friends. These flags tell maven to spew verbose information that may help you to glean some insights.
