Pitfalls in Maven2

we (me and a co-worker) are currently working on replacing some unmaintainably large ant-scripts by using maven2. from the beginning it was a goal to avoid using maven-ant-plugin and instead rebuild (and so restructure) the old scripts. here are a few pitfalls we suffered from, so maybe you don´t have to ;)

• use a dependency to the (very) latest maven APIs instead of 2.0. we were puzzled for a day when coding a mojo that had to handle dependencies, just to find out that the getDependecies() call was added to MavenProject in some minor release.
  
  
• when converting from other build-tools, be sure to put resources to srv/main/resources instead of src/main/java. most IDEs create resources (like .properties for instance) directly in the source-tree. we created a plugin-mojo to take care of moving those resources. contact me if you could use that code.
  
  
• if you generate code, tell maven where to find it. this is done by letting maven inject the project into your mojo and registering your source directory by calling:
  
/**
* @parameter expression="${project}"
* @required
*/
private MavenProject project;
public void execute() throws MojoExecutionException, MojoFailureException
{
String outputDirectory; /* maybe injected if you want to configure it. */
[...]
project.addCompileSourceRoot(outputDirectory);
}


• If you happen to generate anything in the src/ tree (which is best to avoid anyway) be sure that this would not interfere with other people (or continuum) checking out the projects. we faced this problem, because some generator created files and continuum blew all our projects to 'broken' state because cvs update did not work anymore (file xy is in the way).
  
  
• use the m2-proxy to realize a local 'central' repository. If you don´t, you may be experiencing productivity loss when the real central is unavailable and you realize, you cannot do anything productive without maven anymore ;)
  Furthermore, use a good (read 'long') caching value for the central repository, so that (slow) outside communication is limited to a reasonable minimum.
  
  
• if you are working in a team and work with snapshots of team-created artifacts, be sure to know what mvn -U means ;) it is quite easy to fall into this one. in our case, best is to make -U a rule in order not to miss anything important. with a decent proxy, it does not hurt performance that much.
  

anyway. maven2 is a great project. even though the learning curve is a little hard if you want to do non-standard stuff (signing jars, obfuscating, code-generation with a home-grown generator etc), it definately eases our every-day life.