Channels ▼


Maven: Building Complex Systems

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 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 and elements in the top-level POM file since this plugin is not distributed through the standard ibiblio repository where it can be found automatically.

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.