[PATCH/CHANGE] JUnitReport

[Stephane Bailliez <sb...@imediation.com>]

For the sake of simplicity, either because XML parser hell, Xalan
versioning, and customization. 
I would like to remove the 'report' element in the junitreport task so that
users make use of the style task instead. This will be much easier for
everybody.

Code change:
- remove AggregateTransformer.java
- remove xsl directory
- remove html directory
- remove the transformation from the aggregation (see diff)
- add the stylesheet junit-frames.xsl to ./etc. I would like to request etc
directory it as being part of the distribution. It also contains another
useful stylesheet (log.xsl) so I think it has some sense.


Now creating a framed html report is a simple matter of doing :

        <style processor="xalan" in="./reports/xml/TESTS-TestSuites.xml"
out="./reports/html/dummy.file" style="./junit-frames.xsl">
        	<param name="output.dir"
expression="'${basedir}/reports/html'"/>
        </style>

I can certainly arrange something to maintain backward compatibility (and
avoid the tedious typing of the style task) but in this case here's my
proposal.

- Call directly the main class org.apache.xalan.xslt.Process in the report
code. This will need to set a SecurityManager to avoid System.exit call for
the time the stylesheet rendering is performed. We cannot rely on running an
external JVM because some output requires an enormous amount of memory that
may need to be tweaked depending on expected output. So it is better to run
it in the Ant VM.

- Alternative solution to the main class, is to do the call to Xalan 2.x and
Xalan 1.2.2 via reflection to avoid compile time and/or runtime problems.

Another problem to maintain compatibility and avoid stylesheet duplication:
I would have to get the stylesheet using ${ant.home}/etc/<stylesheet-name>.

If backward compatibility has to remain, then for now you can avoid applying
the diff. But I would like the stylesheet to be committed so that current
1.3 users get it easily if they feel the need to do so.

-- 
 Stéphane Bailliez 
 Software Engineer, Paris - France 
 iMediation - http://www.imediation.com 
 Disclaimer: All the opinions expressed above are mine and not those from my
company. 

Re: [PATCH/CHANGE] JUnitReport

[Stefan Bodewig <bo...@apache.org>]

On Wed, 11 Jul 2001, Stephane Bailliez <sb...@imediation.com>
wrote:

> I can certainly arrange something to maintain backward compatibility
> (and avoid the tedious typing of the style task) but in this case
> here's my proposal.

If you know which style task one would have to use, you could fake it
using project.createTask("style") and populate the attributes
yourself, no?

> If backward compatibility has to remain, then for now you can avoid
> applying the diff.

Not sure, I've seen you poll on ant-user and think this is a good
idea.  The change would have the biggest impact for people that have
their own modified versions of your original stylesheets, right?
People that use the task in default setup, wouldn't have to change
anything.

> But I would like the stylesheet to be committed so that current 1.3
> users get it easily if they feel the need to do so.

Let's see where we are going to end up with this discussion,
committing something to /etc could be done five minutes before a
feature freeze starts 8-)

Stefan