gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: JUnit reports & Gump
Date Sat, 05 Apr 2003 22:38:00 GMT
Sam Ruby wrote:
> Leo Simons wrote:
> I want 
>> to make the results of <junitreport/> available through GUMP.
 >
> Here's a brief overview of how gump works internally, relative to 
> javadoc.

tah!

an addition or two and comments so far....

> Everything I say would apply to junitreport.

and indeed, it does...

> Jenny is a java program which is responsible for merging together all of 
> the xml descriptions into a single work/merge.xml file.  In the process, 
> it resolves, verifies and cleans up everything.  The key files affected 
> in this is workspace and project - as you will need an javadoc element 
> in workspace to identify where (and if) the output will be placed (both 
> the directory and url), and project.java will need to handle the element 
> you have already mentioned.
> 
> Now comes the twist: project.java places all the fully resolved javadoc 
> information onto the associated module element.  Define the javadoc 
> element in your workspace and "build gump gen" to see what is produced. 
> Look for javadoc elements with nested descriptions.  The descriptions 
> will have fully resolved source, dest, and url attributes.
> 
> You can debug your work so far simply by inspecting the generated 
> work/merge.xml.  Admittedly, the DOM level manipulations that will be 
> required in Project.java aren't that fun or elegant, nor, however is 
> this very hard and you can simply clone resolveJavadoc to get you started.

Another way to describe what happens is that a giant DOM tree is built 
from the various xml files using some procedural java logic, with each 
type of xml file having its own parser. The format of merge.xml is not 
actually specified or important. Merge.xml is an xml file of icky size 
and setup :D

> The next step is the one that actually makes it all happen.  It also is 
> the easiest.  The stylesheet/pubdocs.xsl produces a perl script.  Don't 
> let that freak you out.  The script creates a map (HashMap in javaterms) 
> of sources and destinations, and iterates over them, copying directories 
> as it goes.  Simply clone the template for javadoc, adjust as necessary, 
> and the junitreport files should be added to the map.  Visually inspect 
> pubdoc.pl to see what I mean.

note: this script is not generated 'by default'. There are some extra 
ant targets in the gump build.xml file which generate some extra 
optional files, and this is one of them. Run 'ant pubdocs' to generate 
the javadoc publish script. Of further note is that this script does not 
make use of rsync atm, which is prolly easily added though and it is a 
good idea to do so (patch pending ;).

> The next step is to where most of the thought will go into.  Look at 
> stylesheet/xref.xsl.  Search for javadoc.  This is what produces the 
> following:
> 
> http://nagoya.apache.org/~rubys/gump/javadoc.html
> 
> If you look closely, all of the jakarta commons projects are under the 
> jakarta commons module.  Single project modules are formatted 
> differently.  Hopefully, most of the logic should be the same, but if 
> there is any creativity required, this would be the area.

I think XSL is more difficult to unroll than assembler. Icky, icky, very 
icky stuff. IMHO no sane person should be made to read, let alone write, 
XSL sheets! :P

> Finally, please update site/xdocs as appropriate.

Aside from that, I think I'm done (your comments kinda made things a 
snap). See patch. I'm going to test things tomorrow (so don't apply yet!).

g'night,

- Leo

Mime
View raw message