Mental Echo

Handling Broken Maven Plugins

Created: June 23, 2009 / Updated: June 23, 2009

Oh, the joys of using maven.  I had the great opportunity today to spend an extended amount of time on a task that should have required 10 seconds of typing and about 20 seconds of waiting.  All I wanted to do was check out a new project from subversion and run "mvn eclipse:eclipse" so that I could import the project into Eclipse.  Unfortunately, about a week ago, while doing a similar thing, I must have downloaded the latest version of the maven eclipse plugin (version 2.7) which decided that it was going to throw up all over itself.

The problem ended up being the inclusion of two elements in the pom that pointed to the same directory (src/main/resources).  This is totally legal and very much necessary for the project in question.  The first block uses filtering and includes a couple of files while the second resource block does not do filtering and excludes the files from the first block.  It is basically a standard way to put all resources in one directory and filter some of them, while not filtering a certain set, for instance binary files like images which will react poorly to filtering.  Regardless, the new version of the maven eclipse plugin couldn't handle this while its predecessor versions had no trouble with it.  To be exact, the error that pops out is Request to merge when 'filtering' is not identical.

Now there are a couple of ways to handle this.  One way would be to explicitly put the version of the plugin that I want into the pom of the project.  This works, however I would need to do this in every project or put it into a parent level pom that all projects inherit from.  Again, that works, but my main issue with this solution is that it now puts IDE specific information into our projects which really shouldn't care what the development environment is.  And this error really only effects myself and the two other developers on the team that use Eclipse, not the four guys that use NetBeans or the one crazy mofo that uses emacs.  Another solution would be to specify the plugin version number on the command line.  This works as well, but my tiny monkey brain is well trained to type "mvn eclipse:eclipse' without thinking about it and I would never remember to get it right.

The solution that seems to make the most sense at this time is to use a plugin-registry.xml file, which prior to today I have never heard of.  Thanks to the crazy emacs mofo mentioned earlier for pointing me in the direction of this link that describes how to set up the plugin-registry.xml file.  If you want to skip reading through the info on the link, here is the cliff notes version...
 
Go to your settings.xml file and add "<usePluginRegistry>true</usePluginRegistry>" directly under the opening tag.  Then create a file called plugin-registry.xml in the same directory as your settings.xml file.  (NOTE: maven will auto create this file if you run any maven command at this point, but it is probably easier just to create it ourselves).  In the plugin-registry.xml file, add the following content...

<?xml version="1.0" encoding="UTF-8"?><pluginRegistry>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-eclipse-plugin</artifactId>
      <useVersion>2.6</useVersion>
      <rejectedVersions>
        <rejectedVersion>2.7</rejectedVersion>
      </rejectedVersions>
    </plugin>
  </plugins>
</pluginRegistry>

This is basically telling maven that we currently want to use v2.6 and that v2.7 is rejected for all of eternity.  When a new version gets released eventually, you will be prompted the next time you run an eclipse plugin goal and you can decide whether to use the latest version or not.  Maven will automatically update the plugin-registry.xml file for you based on what you decide.
 
Maven is in the process of redesigning this functionality as the warning on the top of the earlier link states, but for now, it works pretty well.

Like all maven bugs, it sucks and takes you a bit to figure out, but going forward I have a quick and easy way to get around broken plugins.  If anyone knows why they decided to break the eclipse plugin, I'd love to know.

Tags: Maven, Eclipse
Categories: SoftwareDev


Recent Posts

Handling Broken Maven Plugins
Book Review - A Whole New Mind
Portfolio Viewer on Computer World
Onwards and Upwards
Book Review: Made To Stick

Archive

June 2009 (2)
September 2008 (1)
June 2008 (1)
April 2008 (2)

Tags

AdobeAIR (1)
Books (3)
Communication (1)
Eclipse (1)
Marketing (1)
Maven (1)
PortfolioViewer (1)

Categories

Books (4)
General (2)
SoftwareDev (1)
Technology (1)