maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: Plugin parameters
Date Wed, 30 Mar 2005 15:35:13 GMT

> -----Original Message-----
> From: Emmanuel Venisse []
> Sent: Wednesday, March 30, 2005 3:07 PM
> To: Maven 2 Developers List
> Subject: Plugin parameters
> Hi,
> Can we change the plugin parameter definition from class 
> comment to field
> comment for obtain a more readable source?
> Actually, we have :
> /**
>  ...
>  * @parameter name="outputDirectory"
>  * type="String"
>  * required="true"
>  * validator=""
>  * expression=""
>  * description=""
>  ...
>  */
> Can we replace this by :
> /**
>  * Description is here like a javadoc comment
>  * @parameter
>  * alias="optional name that replace the field name"
>  * required="true"
>  * validator=""
>  * expression==""
>  */
>  String outputDirectory="aDefaultValue";
> => the type isn't an attribute of parameter but the type of field
> I'm not sure if it's possible for inherited classes with 
> inherited parameter
> field.
It is possible with qdox (and quite easy) if classes are residing in the
same module.

You make take a look at plexus-cotlet module which does that
It is capable to generate component descriptors and xdoc documentation from
javadoc tags.

There is almost no diff between ordinary plexus component (ODC) and maven
plugin. Only "expression" attribute does not make sense in case of ODC
(mayeb it can denote context variable?).

It should also be doable to create plugin decsriptors in case of plugins,
which import classes which are used as plugin parameters from other modules.
I made some experiments to implemnet that some times ago and wanted to add
it to plexus-cdc, but it was rejected and
the vison that components should not cross jar boudaries won at that time.
In that case simply some sort of merger, which merges metadata found by qdox
with metadata which exists in xml files in other modules is needed in case
of plexus component. I suppose that in case of maven plugins the situation
is not much different (probably expression" attribute may bring some
problems here).
INn such case maulaly edition of plugin descriptor may be a solution.

Note also that in early days of plugin api we tried to use exactly that
stratgy and levarge xstream for populating plugin fields. 
If I am right the samples of markup and how it used to work should still
exist in cvs. Honstly I was always finding that way of feeding plugins with
params to be superior as it makes the code much more readable.


View raw message