to the Jelly context within the vdoclet velocity templates. Thus, as a
result, support of the maven.tasklist.taskTag was dropped and the
tasklist plugin was hardcoded to use "@todo" because there was no way to
get the value from the Jelly context.
- VDocletBean can now be passed a JellyContext which gets wrapped in the
same JellyContextAdapter that I wrote from the Velocity taglib. To
access the context from a vdoclet template, use '$jellyContext'.
- Updated the taglib and tag defined in plugin.jelly to automatically
include the current context.
- Updated the POM to include the jelly deps. On a side note, also had
to update the POM of the xdoc plugin as it had a dependency on the
velocity taglib as well, and it was being loaded before the jar
specified in this POM.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@113032 13f79535-47bb-0310-9956-ffa450edef68
excel files in his site. Rather than make some "special" directory,
I've modified the xdoc plugin to copy over anything from the xdoc
directory instead of just *.htm[l] files. This excludes the CVS
directories and any *.xml files.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@112999 13f79535-47bb-0310-9956-ffa450edef68
The following patch corrects a number of bugs in the maven-report.xml.
The bugs include not checking for the existance of the tasks.xml and
changes.xml which results in links being added to the report summary
page that don't refer to anything.
Cheers, Steve.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@112965 13f79535-47bb-0310-9956-ffa450edef68
its more descriptive. The docs are always generated, this property is
just a little shortcut to have them not displayed in the navigation bar.
I've also updated the documentation to reflect this change.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@112834 13f79535-47bb-0310-9956-ffa450edef68
"Project Documentation" section of the navbar (i.e. the Maven generated
stuff). This is useful for documentation sites only. The new property
is:
maven.xdoc.generateProjectDocumentation = yes
If you want to disable the generation, set this value to 'no' in your
project.properties.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@112833 13f79535-47bb-0310-9956-ffa450edef68
should use a LinkedHashSet, but that isn't part of 1.3. So we'll just
use an ArrayList and create a new list each time this goal is invoked
which will prevent duplicates from being added.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@112790 13f79535-47bb-0310-9956-ffa450edef68
appear in their published site's "Project Reports" section of the
navbar. Users can now specify a <reports/> section in the POM that
specifies exactly which reports should be included in one's site. For
example:
<reports>
<report>maven-changelog-plugin</report>
<report>maven-junit-report-plugin</report>
<report>maven-javadoc-plugin</report>
<report>maven-jxr-plugin</report>
</reports>
This would only run the above four plugins when 'maven site' is invoked.
In addition, the navbar and the maven-reports document that is generated
will only contain links to the above specified reports. Please note,
that the order the reports are specified is the order in which they will
appear. Note: if you do not have a <reports/> section in the POM, you
will fallback to the standard behavior (which is predefined reports).
Lets talk about how this all works now. Previously, site.jsl in the
xdoc plugin contained a static set of reports that were included in the
navbar. This could not be changed by end users. In addition, we also
had a separate xdoc to maintain which contained a description of all of
the reports (this page is displayed when you click on 'Project Reports'
to expand that section of the navbar). Again, this was a static page.
Finally, a developer writing their own plugin which generated a report,
would have to submit patches for both of these files for their report to
be included when a 'maven site' was executed.
All of the above deficiencies have been corrected when using the new
<reports/> mechansim. There is a new protocol which plugin developers
should follow if their plugin generates a report. Their plugin's
plugin.jelly file should contain a gool like this (don't forget to
include the 'xmlns:doc="doc"' declaration as well):
<goal name="maven-changelog-plugin:register">
<doc:registerReport
name="Change Log"
link="changelog-report"
description="Report on the source control changelog."/>
</goal>
The above should be pretty self explanatory. The plugin developer
simply defines a 'name'. The 'name' is used in the navbar and in the
first column of the table in the auto-generated maven-reports file.
'link' is the relative link from the doc directory to the generated
report (without the extension). Finally, a 'description' should be used
to create a one line summary of the report's contents. This is used
when auto-generating the maven-reports document.
A plugin may define multiple reports if needed. For example, here is
the javadoc plugin example:
<goal name="maven-javadoc-plugin:register">
<j:if test="${sourcesPresent}">
<doc:registerReport
name="JavaDocs"
link="apidocs/index"
description="JavaDoc API documentation."/>
<doc:registerReport
name="JavaDoc Report"
link="javadoc"
description="Report on the generation of JavaDoc."/>
</j:if>
</goal>
Another important difference you'll notice above is that the conditional
tests of whether or not a report should appear is no longer part of
site.jsl. The logic of determining whether the report appears now lies
within the plugin that generates the report. Thus, in the above
example, only if sources are present, will the reports actually appear
in the navbar and maven-reports document.
So what happens when one types 'maven site'? Basically, for each
<report/> defined, maven will try to <attainGoal> on that report. The
goal runs as it normally does. The magic kicks in when the 'xdoc'
plugin is run (after all of the <reports/> have been run). The first
thing the xdoc plugin does is determine what reports should be included
in all of the documentation it generates. The report list (its really a
set) is generated when xdoc calls its own 'xdoc:register-reports' goal.
This goal looks at each <report/> defined in the POM and then calls
<attainGoal name="xyz:register"/> where "xyz" corresponds to the name
defined in the <report/>. This is where the new protocol is required.
If that goal does not exist, you will get an error from Jelly.
As each of the xyz:register goals are called, they invoke the
<doc:registerReport> tag (which is defined in the xdoc plugin), this tag
basically builds a set of hashtables. Each hashtable corresponds to a
report and contains a 'name', 'link', and 'description' entry. After
the completion of 'xdoc:register-reports' we now have a set in the xdoc
context called 'reports' which contains our descriptions of each report.
Site.jsl uses this to dynamically build up the navbar, and the
maven-reports document uses it to build the content of itself.
Phew! That was a long one. In summary, if you don't use <reports/>
nothing changes (at least it shouldn't), but in the future, if this
<reports/> thing works out, we will migrate users in this direction.
git-svn-id: https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk@112789 13f79535-47bb-0310-9956-ffa450edef68
