[
http://jira.codehaus.org/browse/MNGSITE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-3273 to MNGSITE-39:
-----------------------------------------------
Component/s: (was: Documentation: Guides)
Key: MNGSITE-39 (was: MNG-3273)
Project: Maven Project Web Site (was: Maven 2)
> Point out known pitfalls when developing plugins
> ------------------------------------------------
>
> Key: MNGSITE-39
> URL: http://jira.codehaus.org/browse/MNGSITE-39
> Project: Maven Project Web Site
> Issue Type: Improvement
> Reporter: Benjamin Bentmann
> Assignee: Vincent Siveton
> Priority: Minor
> Attachments: pitfall-report-output-directory.patch,
> pitfalls-resource-bundles.patch, pitfalls-resource-bundles.patch,
> pitfalls.patch, plexus-utils.patch, plugin-api-logger.patch
>
>
> 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
