You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Vincent Siveton (JIRA)" <ji...@codehaus.org> on 2008/02/07 03:54:31 UTC

[jira] Closed: (MNG-3273) Point out known pitfalls when developing plugins

     [ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vincent Siveton closed MNG-3273.
--------------------------------

    Resolution: Fixed

Applied. Thanks!

> 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
>            Assignee: Vincent Siveton
>            Priority: Minor
>         Attachments: pitfall-report-output-directory.patch, pitfalls-resource-bundles.patch, pitfalls-resource-bundles.patch, pitfalls.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