docbook-apps

When I was setting up our Ant based tool chain I could not find a way to get the Ant <xslt> task to support xinclude processing without doing two passes: one to resolve the xincludes then one to process the content. Since we are also using profiling that resulted in a three stage process (5 if we tagged on PDF processing).
It seemed easier and faster to use Saxon from the <java> command.


-----Original Message-----
From: Tony Graham [mailto:Tony.Graham@MenteithConsulting.com]
Sent: Thu 4/10/2008 8:46 AM
To: docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] ant and db5, xinclude and fo output

On Thu, Apr 10 2008 11:36:06 +0100, davep@dpawson.co.uk wrote:
> My latest foray into ant:
...
> <target name="fo" depends="init, clean.pdf">
> <echo>Generate the fo output</echo>
> <java classname="${xslt.processor.class}"
> fork="yes"
> dir="${in.dir}"
> failonerror="true">
> <classpath refid="xslt.processor.classpath" />
> <jvmarg
> line="-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration"/>
> <jvmarg
> line="-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"/>
> <jvmarg
> line="-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl"/>
> <arg line="-o ${out.fo.dir}/${main.fo.outfile}"/>
> <arg line="-l"/>
> <arg line="-x org.apache.xml.resolver.tools.ResolvingXMLReader"/>
> <arg line="-y org.apache.xml.resolver.tools.ResolvingXMLReader"/>
> <arg line="-r org.apache.xml.resolver.tools.CatalogResolver "/>
> <arg line="${in.dir}/${main.infile} ${main.fo.stylesheet} " />
> </java>
> </target>
>

The Ant manual [1] recommends <arg value="..."/> rather than <arg
line="..."/>. Doing so needs more elements, but it's safer to use.

Why are you using the <java> task rather than the <xslt> task? IMO,
using the <xslt> task makes using XML catalogs with Ant much easier.

You could also make a macro for the transformation so you wouldn't need
to repeat everything just to change three filenames.

...
> It might be nicer to use xmllint to expand the includes and validate,
> but I haven't figured out how to get ant to do that.

<exec> [2].

Regards,


Tony Graham Tony.Graham@MenteithConsulting.com
Director W3C XSL FO SG Invited Expert
Menteith Consulting Ltd
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599 http://www.menteithconsulting.com
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
xmlroff XSL Formatter http://xmlroff.org
xslide Emacs mode http://www.menteith.com/wiki/xslide
Unicode: A Primer urn:isbn:0-7645-4625-2

[1] http://ant.apache.org/manual/using.html#arg
[2] http://ant.apache.org/manual/CoreTasks/exec.html
I don't know why it's showing as "beta" since it was in earlier
versions of Ant than the Ant 1.7 currently documented at this URL.

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

On Thu, Apr 10, 2008 at 2:20 PM, Johnson, Eric <Eric.Johnson@iona.com> wrote:
> one to resolve the xincludes then one to process the content. Since we are
> also using profiling that resulted in a three stage process (5 if we tagged
> on PDF processing).
> It seemed easier and faster to use Saxon from the <java> command.

Separate passes certainly makes it a lot easier to figure out what is
wrong if something breaks in the publishing chain...

S