> /**
> * @parameter expression="${project.build.outputDirectory}"
> */
> private File outputDirectory;
>and
> /**
> * @parameter default-value="${project.build.outputDirectory}"
> */
> private File outputDirectory;
Interesting problem. I usually prefer to use the expression for anything
property related and default-value to specify a value in the case the
property didn't resolve.
>Here the expression is not backed by the POM and hence usually resolves
to
>null. It would be rather useless to report "${someSystemProperty}" as
the
>default value.
If we see a property syntax in the default-value, why not display it as
though it was an expression? Expressions currently show the property
name on the site.
>Currently I believe, plugin developers need to address this
individually by
>using "default-value" instead of "expression" when appropriate because
there
>does not seem to be an easy/reliable heuristic how the
PluginXDocGenerator
>can detect those cases.
I agree it should be consistent and this comes back to documenting the
best practices so everyone knows.
> /**
> * @parameter expression="${project.build.outputDirectory}"
> * @required
> */
> private File outputDirectory;
>i.e. use a POM-backed expression and also mark the parameter as
required.
>Again, from the user's point of view, this parameter is not required.
It can
>be safely ommited in the plugin configuration because the POM
expression
>will fill it in.
The plugin annotation parser should be smart enough to see this as well
and ignore the @required if an expression or default-value is given.
>I know, that's all peanuts but Maven's documentation is often critized
and I
>feel this point is not on the good site. What do you think?
I agree these are important, and we need to document and then fix them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
