maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bentmann (JIRA)" <j...@codehaus.org>
Subject [jira] Reopened: (MNG-3273) Point out known pitfalls when developing plugins
Date Tue, 08 Jan 2008 10:51:57 GMT

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

Benjamin Bentmann reopened MNG-3273:
------------------------------------


Just found another anti-pattern that does not seem to be common knowledge.

> 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: pitfalls.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

        

Mime
View raw message