Intermittent exceptions when using a subclass of JavaExec to invoke the Saxon XSLT processor

Old Forum Archive
1

I’m trying to write a Gradle 1.9 build file that will perform DocBook XSLT transformations using the Saxon processor. My builds succeed and fail sporadically, often without me making any changes to the code or build environment. I’m new to Gradle and this is my first project. Has anyone seen intermittent exceptions when using JavaExec?

I’m using a subclass of JavaExec to invoke Saxon 6.5.5. I haven’t completed the build file yet but it seems to be working properly (sometimes) because I’ve seen successful builds and correctly transformed output XML files.

I see two different exceptions when the builds fail. One is a problem casting the main class name string. The other is a problem matching my arguments to the class constructor. Oddly, if I run the build repeatedly sometimes making white space changes to the code and sometimes deleting the .gradle and artifact directories, I can cycle through successful builds and both exceptions.

Here’s the main class casting exception:

Caused by: org.codehaus.groovy.runtime.typehandling.GroovyCastException:

Cannot cast object ‘com.icl.saxon.StyleSheet’ with class ‘java.lang.String’

to class 'org.gradle.api.tasks.JavaExec

Here’s the constructor argument matching exception:

Caused by: org.codehaus.groovy.runtime.typehandling.GroovyCastException:

Cannot cast object '[-o, C:\mypath\build\man-page.xsl,

C:\mypath\publishing-files\utilities\write-local-customization-layer.xsl,

C:\mypath\publishing-files\utilities\write-local-customization-layer.xsl,

docbook.xsl.dir=C:/publishing-tools/docbook-xsl-ns-1.78.0,

stock.stylesheet.path=/manpages/docbook.xsl,

customization.stylesheet.path=C:\mypath\publishing-files\output-customization\man-page.xsl]’

with class ‘java.util.ArrayList’ to class ‘org.gradle.process.JavaExecSpec’ due to:

groovy.lang.GroovyRuntimeException: Could not find matching constructor for:

org.gradle.process.JavaExecSpec(java.lang.String, java.io.File, java.io.File,

java.io.File, java.lang.String, java.lang.String, org.codehaus.groovy.runtime.GStringImpl)

at Saxon6.constructArgs(C:\mypath\build.gradle:88)

at Saxon6.exec(C:\mypath\build.gradle:94)

at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)

Here’s the class that extends JavaExec:

class Saxon6 extends JavaExec {
    def output
    def input
    def stylesheet
    def extraArgs
    public Saxon6() {
      main = "com.icl.saxon.StyleSheet"
      systemProperties = [
        "javax.xml.parsers.DocumentBuilderFactory": "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl",
        "javax.xml.parsers.SAXParserFactory": "org.apache.xerces.jaxp.SAXParserFactoryImpl",
        "org.apache.xerces.xni.parser.XMLParserConfiguration": "org.apache.xerces.parsers.XIncludeParserConfiguration",
      ]
      classpath = project.configurations.saxon6 + project.configurations.xmlResolver + project.configurations.xerces
    }
      private void constructArgs() {
      args = ['-o', output, input, stylesheet ] + extraArgs
    }
      @TaskAction
    @Override
    public void exec() {
      constructArgs()
      super.exec();
    }
  }

I’m using Cygwin to run Gradle and JDK 1.7.0.

$ gradle -v

------------------------------------------------------------ Gradle 1.9 ------------------------------------------------------------

Build time:

2013-11-19 08:20:02 UTC Build number: none Revision:

7970ec3503b4f5767ee1c1c69f8b4186c4763e3d

Groovy:

1.8.6 Ant:

Apache Ant™ version 1.9.2 compiled on July 8 2013 Ivy:

2.2.0 JVM:

1.7.0 (Oracle Corporation 21.0-b17) OS:

Windows NT (unknown) 6.2 amd64

Thanks for your help!

2

Slightly off-topic but any time anyone wants to use XSLT I always try to steer them towards Freemarker. IMHO the resultant transformation code is less verbose and much easier to read and maintain.

http://freemarker.org/docs/xgui_imperative_learn.html http://freemarker.org/fmVsXSLT.html

3

Thanks for the suggestion. I need to write this using Gradle because the transformation is part of a much larger software build process that uses Gradle.

4

I’m not suggesting you ditch gradle… I’m suggesting you ditch xslt in favour of freemarker

5

I’m not suggesting you ditch gradle… I’m suggesting you ditch xslt in favour of freemarker

6

Ah. I see. That does look interesting. Our publishing tool set is based on XSLT so I’d prefer to figure out the Gradle problem.

7

I encountered the same issue and I was able to solve it by calling

setMain(“com.icl.saxon.StyleSheet”)

instead of doing

main = “com.icl.saxon.StyleSheet”