That’s exactly what I was going to suggest.  (ie passing the “-o” and the 
file-name as separate parameters).
Some time ago when I got Saxon 6.5.5 working from Ant that’s exactly what I had 
to do.
Saxon 9 takes “-o:file-name”, ie the colon means that it is a single keyword, 
where Saxon 6 makes it two “-o file-name”.


Richard Kerry
BNCS Engineer, SI SOL Telco & Media Vertical Practice

T: +44 (0)20 3618 2669
M: +44 (0)7812 325518
Lync: +44 (0) 20 3618 0778
Room G300, Stadium House, Wood Lane, London, W12 7TA<>


From: Dominik Psenner []
Sent: Thursday, August 10, 2017 9:13 AM
To: DocBook Apps <>
Subject: Re: [docbook-apps] Gradle build cross-platform - trouble with Saxon 
6.5.5 params under Windows

2017-08-10 8:30 GMT+02:00 Dave Pawson 
Worth asking on the docbook-apps list Peter?

This is the docbooks-apps list, isn't it?

I use 2 for other parts, but for my main (quite large) docbook build I use 1.
  I use ant.

Peter, you could try giving "-o" and "myoutputfile.xml" as separate arguments. 
If you would build this with Go-Cd, it would require you to configure the build 
task arguments like this:


and thus treating every line as a separate argument. Writing it like this would 
not work:

-o myoutputfile.xml

You could also try wrapping `myoutputfile.xml` in quotes.

On 10 August 2017 at 05:14, Peter Desjardins
<<>> wrote:
> Hi! I have a working Gradle build system that transforms DocBook 5.1
> (using an assembly) to a few output mediums. I'm using Saxon 6.5.5 and
> the DocBook XSLT 1.0 stylesheets (latest version). When a new writer
> chose to use Windows, the Gradle build broke when she ran it locally.
> Problem #1 is that the Gradle exec task that assembles the DocBook
> assembly using Saxon 6.5.5 won't work under Windows. Saxon complains
> that there's "no output file name." Gradle has a terrible problem
> consuming the "-o myoutputfile.xml" argument.  If I present the "-o"
> argument separately, Saxon claims that the output file name is
> missing. If I present a "-o myoutputfile.xml" argument, Saxon
> complains that  "-o myoutputfile.xml" isn't a recognized argument. Has
> anyone built a Gradle Exec task that runs Saxon 6.5.5 on Windows? It
> works just fine on Linux and MacOS.
> Question #2 is: Has anyone had trouble using Saxon9HE with the DocBook
> XSLT v1.0 stylesheets? The way the arguments for the later version of
> Saxon are structured work much better with Gradle.
> (-o:myoutputfile.xml.)
> I'm considering switching to the DocBook XSLT 2.0 stylesheets to work
> around this problem. That avoids mixing Saxon9HE with the DocBook XSLT
> 1.0 stylesheets. Has anyone had any trouble migrating to XSLT 2.0?
> Thanks for your help!
> Peter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 

Dave Pawson
Docbook FAQ.

To unsubscribe, e-mail:<>
For additional commands, e-mail:<>

Dominik Psenner
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at 4 Triton 
Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

Reply via email to