You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org> on 2007/11/06 00:33:35 UTC
[jira] Created: (MNG-3273) Point out known pitfalls when developing
plugins
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
[jira] Issue Comment Edited: (MNG-3273) Point out known pitfalls
when developing plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119150 ]
bentmann edited comment on MNG-3273 at 1/8/08 8:53 AM:
----------------------------------------------------------------
bq. (more can be found in the "Parameter Expressions" document)
Where is this "Parameter Expressions" document? Is http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide meant or something else? Whatever, either a hyperlink to the target document should be established or the phrase should be deleted (in case this document does not exist, no need to point users into nirvana).
Really off-topic: Is it be intention or by accident that this JIRA project does not allow formatting/markup in comments?
was (Author: bentmann):
bq. (more can be found in the "Parameter Expressions" document)
Where is this "Parameter Expressions" document? Is http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide meant or something else? Whatever, either a hyperlink to the target document should be established or the phrase should be deleted (in case this document does not exist, no need to point users into nirvana).
Really off-topic: Is it be intention or by accident that this project does not allow formatting/markup in comments?
> 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-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
[jira] Updated: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-3273:
-----------------------------------
Attachment: plexus-utils.patch
> 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, 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
[jira] Reopened: (MNG-3273) Point out known pitfalls when
developing plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann reopened MNG-3273:
------------------------------------
I noticed Dennis pointing out the requirement to use Maven 2.0.6 as prerequisite if plexus-utils != 1.1 should be used [0|http://www.nabble.com/Re%3A-svn-commit%3A-r616959---in--maven-plugins-trunk-maven-help-plugin%3A-pom.xml-src-main-java-org-apache-maven-plugins-help-SystemMojo.java-src-site-apt-index.apt-src-site-apt-usage.apt-td15216930s177.html], [1|http://www.nabble.com/Re%3A-svn-commit%3A-r627125----maven-plugins-trunk-maven-compiler-plugin-pom.xml-to15443813s177.html]. It seems this subtle point is not properly documented.
> 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, 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
[jira] Updated: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-3273:
-----------------------------------
Attachment: pitfalls.patch
bq. java.io.File resolves relative paths (i.e. outputDirectory = "target/something" ) against the current directory which is the project base directory
No, the current directory can be different from the project base directory (e.g. user calls Maven with -f switch or during reactor build).
bq. Maven should automatically push in properly resolved paths into the mojo.
"should"? I kind of feel a little nervous when the Maven developers themselves start talking about what Maven "should" and not what it "does" ;-)
> 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
[jira] Updated: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-3273:
-----------------------------------
Attachment: pitfall-report-output-directory.patch
Another pitfall I have seen more than once... Patch intended to supplement MNG-3369.
> 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
[jira] Commented: (MNG-3273) Point out known pitfalls when
developing plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119150 ]
Benjamin Bentmann commented on MNG-3273:
----------------------------------------
bq. (more can be found in the "Parameter Expressions" document)
Where is this "Parameter Expressions" document? Is http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide meant or something else? Whatever, either a hyperlink to the target document should be established or the phrase should be deleted (in case this document does not exist, no need to point users into nirvana).
Really off-topic: Is it be intention or by accident that this project does not allow formatting/markup in comments?
> 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-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
[jira] Updated: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-3273:
-----------------------------------
Attachment: plugin-api-logger.patch
Yet another try to improve the documentation, this time targetting the javadocs for the Plugin API.
> 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-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
[jira] Updated: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-3273:
-----------------------------------
Attachment: pitfalls-resource-bundles.patch
Proposed addition to the pitfalls section about resource bundle families and their proper creation.
> 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-resource-bundles.patch, 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
[jira] Closed: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vincent Siveton closed MNG-3273.
--------------------------------
Assignee: Vincent Siveton
Resolution: Fixed
Added your pitfalls proposal in r609135
> 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
>
> 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
[jira] Closed: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Closed: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Lundberg closed MNG-3273.
--------------------------------
Resolution: Fixed
Patch applied. Thanks Benjamin!
> 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, 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
[jira] Reopened: (MNG-3273) Point out known pitfalls when
developing plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann reopened MNG-3273:
------------------------------------
> 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-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
[jira] Moved: (MNGSITE-39) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Closed: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vincent Siveton closed MNG-3273.
--------------------------------
Resolution: Fixed
applied
> 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-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
[jira] Closed: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vincent Siveton closed MNG-3273.
--------------------------------
Resolution: Fixed
patch applied in r609305. 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: 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
[jira] Commented: (MNG-3273) Point out known pitfalls when
developing plugins
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119915 ]
Vincent Siveton commented on MNG-3273:
--------------------------------------
Forgot to say that the "Parameter Expressions" document doesnt exist yet (see http://maven.apache.org/docs-required.html )
> 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-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
[jira] Reopened: (MNG-3273) Point out known pitfalls when
developing plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann reopened MNG-3273:
------------------------------------
Not quite happy...
> 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
>
> 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
[jira] Updated: (MNG-3273) Point out known pitfalls when developing
plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-3273:
-----------------------------------
Attachment: pitfalls-resource-bundles.patch
Revised my last patch to include some further tweaks.
> 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-resource-bundles.patch, pitfalls-resource-bundles.patch, 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
[jira] Reopened: (MNG-3273) Point out known pitfalls when
developing plugins
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ 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