> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> > It upgrades Ant Optional tasks to be Xalan 2 compliant and not use
> > any of Xalan 1's API.
>
> We already have TraxLiaison for Xalan2 and XalanLiaison for Xalan 1.
> I know that Stephane has been working on junitreport to replace it
> with an XSL only solution. Stephane, could you please check the
> patches to JUnitReport and see whether they should go into Ant 1.4?
Yes. I was working on it this week end to have some different executor for
xalan2 and xalan1...and use the xalan redirect extension in the xsl.
This allow me to drop about 90% of an unreadable code in
AggregateTransformer.
roughly it is replaced by somthing like:
XalanExecutor executor = XalanExecutor.newInstance(this);
executor.execute();
So that I can search in order for Xalan2 then Xalan1, return the correct
executor and do the serialization. My main concern was the damn backward
compatibility for xalan 1...It would have been easier otherwise...This is
why I did not drop xalan1 and added xalan2 as the default.
I will try to commit it this evening...I have the stuff at home...but
'important point'. I'm getting the xsl from "$ant.home/etc/"..not from the
jar anymore. I can do a copy to the source, but I didn't want to duplicate
it...
This has incidence for the distribution however...
Distrib will contain an etc directory with all xsls.. log.xsl,
junit-frames.xsl, maudit-frames.xsl, mmetrics-frames.xsl,
coverage-frames.xsl. Any -1 for this ?
I think it is convenient for the end user to have all this 'available'
because they can be of use and tweaked.
Or maybe I can do the copy to the right place when doing the distrib... ie
copy the xsl to the package before doing the jar. This could solve the 2
problems w/ one stone.
Any opinion ?
--
Stephane Bailliez
Software Engineer, Paris - France
iMediation - http://www.imediation.com
Disclaimer: All the opinions expressed above are mine and not those from my
company.
