Brian Ewins <[EMAIL PROTECTED]> wrote on 17/12/2002 02:48:49 AM:
> Nice one dion. A few picky comments, (you did ask...)
>
> There's some missing spaces in the docs. Looking at CVS, its not the
> xdoc thats the problem, but something is stripping all the spaces round
> '<code>' tags. Is this an issue with the change from DVSL to JSL? I
> see the same problem with links, eg here:
> http://jakarta.apache.
> org/turbine/maven/reference/plugins/struts/properties.html
Yep, it's a known JSL issue we're trying to fix.
> The war docs don't say what the name of the war is that is built. Its
> always ${pom.id}.war, but people using the jar tasks might wonder why
> there is no version number in the name? eg how do you make a snapshot
> war available without overwriting the production war. When I started
> with maven I looked for that in the docs, had to read the jelly[1]
Cool...will hopefully get to that soon.
> Style-wise, it might be better to have the default goal dependency
> stated explicitly, eg 'pom | executes pom:validate', instead of
> repeating the description of the dependent goal
Given a lot of that stuff is generated from source, I'll see what I can
do.
> The goals.xml files are clearly generated from the plugin.jelly. It
> seems odd that it is the generated file in CVS rather than the code for
> the goal that did the generation? (as in: add a 'plugin:docs' goal, so
> that if no goals.xml exists, it gets generated from plugin.jelly; this
> would allow for improved handwritten docs later)? But then I think its
> odd that there's no 'plugin' plugin to replace all those duplicated
> maven.xmls.... ;)
They're currently in my maven.xml file waiting for me to turn it into a
plugin.
The goals, navigation and properties.xml files were generated if they
didn't previously exist. Goals from plugin.jelly, navigation defaults to a
simple file, and properties.xml from the plugin.properties file.
> [1] BTW I'm not convinced what's been done is the Right Thing; if the
> war file name was a property that could be overridden, then it would be
> easy to write a goal to build (and deploy etc) snapshot/nightly wars.
> Instead, every task explicitly uses ${pom.id}.war. This is an issue in
> our environment, where we want different versions of the war available
> centrally for live use and for the testers. I guess I should stop
> moaning and submit patches :)
+1 :)
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
