default-value is usually what plugin developers want, not expression.
[...]
In other words, expression results should not be allowed to
reflectively query the build state, as in ${project.build.directory},
Thanks for clarifying this. Until you get a proper documentation up and
running, I suggest somebody reviews the Maven core plugins regarding this
topic. If you search for "${project." in the maven/plugins/trunk, you will
find dozens of mojo parameters that use expression rather than
default-value. I assume that many Non-Maven-Team developers (like me) look
at these plugins for an inspiration how things should be handled and
currently Maven's core plugins provide bad examples, that's pitty.
That is, you don't want to allow users to customize this directory
specifically for your plugin (which can be useful for trying to get
plugins to standardize their locations and make them adjustable to
changes in the entire build-output location of ./target), you should
always add @readonly.
Personally, I think this practice should be avoided. Adding @readonly and
therefore hiding the parameter for configuration by the user is a rigid
enforcement. Conventions about directory locations or similar are nice but I
already have heard of people criticising Maven for its strictness, i.e. not
giving users a chance to break with the convention when they (for whatever
reason) need this.
When a plugin developer declares a mojo parameter like
/*
* @parameter default-value="${project.build.directory}/mytool"
*/
private File outputDirectory;
The user can get standardized locations by simply tweaking the
POM.build.directory but he is also free to have some plugin derive from
this.
At least, as Maven is currently implemented. This is because Maven
will always choose *something* for the build directory, and also
because ${missing.value}, when specified directly in the plugin
config for outputDir, will resolve to the literal '${missing.value}'
if you haven't specified a value for that expression in the system
properties or pom properties.
Please note that Maven's evaluation of ${missing.value} does not match your
description. Unknown expressions resolve to null. I had to fight this when I
wanted to pass an expression from the plugin config throught to the plugin
itself, i.e. have the plugin evaluate the expression instead of Maven. In
the end, I had users to escape the expression by doubling the $. I just
verified this with Maven 2.0.8. If not already done, this subtle difference
might be worth an unit/integration test.
Regards,
Benjamin Bentmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
