> +1 I would really like to reorder them as I like. However, there are
> necessary dependencies. Like "jar" depends on "compile". The web site
> also depends on "cross-ref" and almost all others.
>
> Any idea on how to best solve this ?
I like the idea of keeping the target dependencies out of the user's
hair. Right now, all the reports are predefined, but I can see people
wanting to create and share custom reports they've made. Here are the
current predefined reports as I understand them:
* mailing list
* developer list
* dependencies
* unit tests
* metric results
* checkstyle report
* javadocs
* source xreference
There's a number of site related targets that put these together, but
these decorator reports are otherwise pretty unconnected methinks. I'd
propose that a new ant task be created that doesn't the following:
* iterates through all the ant properties with the prefix 'maven.report'
for decorator definitions
Each decorator should look like this:
maven.report.{name-of-decorator}.buildFile
maven.report.{name-of-decorator}.buildTarget
If ordering is important, you could also add
maven.report.{name-of-decorator}.order
They could also be given common names or aliases
maven.report.{name-of-decorator}.alias
Where numbers < 100 would be reserved for maven internal use.
* developers wishing to create optional targets create a
build-{optional-package-name}.xml that can be included with each project
that contain the maven.report.* lines. People wishing to use the
package could import them via
<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY myschtuff SYSTEM "file:build-myschtuff.xml">
]>
<project name="myname" default="mydefault" basedir=".">
&myschtuff;
...
* the navigation.xml file could be modified so that user's could
customize how these options got inserted. Alternative the site.dvsl
file could be modified to just know when these additional things are
present.
* with respect to the site related targets that currently depend on
other targets, I think this mechanism would take care of that by
treating all project documentation as dynamic and dynamically assembling
Ugh ... I've rambled on, but I hope this makes sense.
M
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
