xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: Volunteers: First - cut - Deadline 2nd of March: Shane volunteers
Date Fri, 02 Mar 2001 01:59:23 GMT
Shane Curcuru wrote:
>
> Yes, I know - I'm not ignoring you, I'm... um... actively
> prioritizing in a manner that temporarily addresses certain
> demands in other areas first... yeah.  8-)

;-)

> Short answer on your Gumplog:
> - Conformance test results look appropriate, at a guess.  Someone
> needs to check in a few extra gold files.
> - Minitest portion passed, good.
> - Examples test portion failed, probably cause either the test
> isn't updated for absolute pathnames yet or because Scott moved
> the gold files to a different directory; I'm not really sure this
> test should be in the smoketest target (I'd put some of the other
> API coverage tests there myself).

Not my problem, works, not my problem.  Cool!

> - Exception at the end is probably due to our build script trying
> to call the <style> task.  I tried and tried on my machine, and
> even with optional.jar and such, could never get it to actually
> work for me (hence I only call it if it thinks the right class
> is available).

At the moment, it hardcodes processor="xalan".  Means it won't work with a
trax compliant parser.  If you remove this, it will default to trax (if
present), then xt (if present), then xalan.  In other words, I'd recommend
removing it, or at least allow it to be specified as an Ant property.

(Note1: perhaps I could look into xalanj1compat.jar.  If you fix the others
and would prefer, I will)

(Note2: even when I try with Xalan2, I get the following errors:

    [style] Transforming into D:\jakarta\xml-xalan\test\results-conftest
    [style] Loading stylesheet D:\jakarta\xml-xalan\test\results-conftest\..\viewResults.xsl
    [style] Transforming into D:\jakarta\xml-xalan\test\results-conftest file:D:/jakarta/xml-xalan/test/results-conftest/../viewResults.xsl;
Line 394;
 Column 84; javax.xml.transform.TransformerException
        at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1212)
        at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:2888)
        at java.lang.Thread.run(Thread.java:484)
---------
; SystemID: file:D:/jakarta/xml-xalan/test/results-conftest/../viewResults.xsl; Line#: 394;
Column#: 84
; SystemID: file:D:/jakarta/xml-xalan/test/results-conftest/../viewResults.xsl; Line#: 394;
Column#: 84
javax.xml.transform.TransformerException at org.apache.xalan.extensions.ExtensionHandlerJavaClass.processElement(ExtensionHandlerJavaClass.java:423)
at org.apache.xalan.templates.ElemExtensionCall.execute(ElemExtensionCall.java:304)

)

> Hey: do you have a FAQ or overview document of standards and
> what-not that each project could follow that would make them run
> better in your system? Just a brief list of suggested ways to write
> your Ant build files to make this kind of stuff simpler.  One of the
> things I'm wondering about is why anyone manages classpaths in their
> batch/shell files?  Why not just have build.bat/.sh only add ant.jar
> and some form of xml parser to the classpath, and then always have
> any other classpath items needed be added via properties (which would
> be resettable from outside of the build) and only for the tasks that
> need the extra items on the classpath?

Short answer: use Ant.

I've yet to request that a single project using Ant to change any aspect of
their build process to support Gump.  (Except Avalon - where they didn't
have a target to build something I needed).

- Sam Ruby


Mime
View raw message