> -----Original Message----- > From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] > 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="#project.build.outputDirectory" > * 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=="#project.build.outputDirectory" > */ > 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. michal
