Point out known pitfalls when developing plugins
------------------------------------------------
Key: MNG-3273
URL: http://jira.codehaus.org/browse/MNG-3273
Project: Maven 2
Issue Type: Improvement
Components: Documentation: Guides
Reporter: Benjamin Bentmann
Priority: Minor
Writing a simple Maven plugin is quite easy but getting it wrong is also quite
easy. I am just a novice but have so far noticed two subtle anti-patterns that
plugin developers should avoid. I would expect that the Maven core team knows
some more aspects about mojo programming that plugin developers should be aware
of to fight bugs right from the beginning. All those pitfalls would fit nicely
into [Plugin
Development|http://maven.apache.org/guides/plugin/guide-java-plugin-development.html].
Some examples: It is a bad idea to code something like
{code:java}
public MyMojo {
private Log log = getLog();
public void execute() throws MojoExecutionException {
log.debug("...");
}
}
{code}
Getting the logger this way will retrieve some default logger instead of the
logger that is injected into the mojo (by the plexus container?). This is
easily noticed by the different output styles of the log messages and the fact
that one gets [debug] message without having "-X" enabled.
Not bad but rather dangerous is something like
{code:java}
public MyMojo {
/**
* This parameter will take a file path (file paths are
platform-dependent...)
* @parameter
*/
private String outputDirectory;
public void execute() throws MojoExecutionException {
File outputDir = new File(outputDirectory).getAbsoluteFile();
outputDir.mkdirs();
}
}
{code}
java.io.File resolves relative paths like "target/something" that users might
provide in the plugin configuration against the current directory which needs
not be the project base directory. Therefore, path parameters should be
declared of type java.io.File rather than simple strings as Maven seems to
automatically push in properly resolved paths into the mojo. If one really
needs the parameter to be of type String (i.e. to try resource lookup from
class path), the best practice to properly get an absolute path should be
documented.
How to get a plugin ready for reactor builds might also be worth some warning
words. What does one need to know about aggregator-style execution, execution
project, forking ... ?
A further improvement might be links to recommended libraries like plexus-utils
or plexus-components. This would point peoply to existing code and prevent to
error-prone reinvention of the wheel (only a few things on earth are that
simple that people get them reliably right...)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
