Saxon

I cannot know where Maven locates the dependency JARs on an arbitrary machine.

Other option is to use maven-dependency-plugin to copy all dependencies into the target folder, so ant will know where to look at.

Thank you! Your proposals made my day! :-)

In fact, I am meanwhile using an even simpler solution that does not deal with files at all but passes the classpath as a property:

<plugin>
  <artifactId>maven-dependency-plugin</artifactId>
    <executions>
      <execution>
        <id>dependency-class-paths</id>
        <phase>validate</phase>
        <goals>
          <goal>build-classpath</goal>
        </goals>
        <configuration>
          <outputProperty>classpath</outputProperty>
        </configuration>
      </execution>
    </executions>
</plugin>

<java classname="net.sf.saxon.Transform" classpath="${classpath}" logError="true" fork="true" taskname="xsl">
  <arg value="-o:@{out}" />
  <arg value="-s:@{in}" />
  <arg value="@{style}" />
</java>

While this is a nice workaround, the actual solution would be to convince the maven-antrun-plugin to promote the dependency classpath to ant implicitly (just like it promotes Maven properties as ANT properties). Doing so, nobody would need to invest any effort into such a tedious and error-prone workaround. Hence I hope the Maven people accept my feature proposal: https://issues.apache.org/jira/browse/MANTRUN-237. :-)

While this is a nice workaround, the actual solution would be to convince the maven-antrun-plugin to promote the dependency classpath to ant implicitly (just like it promotes Maven properties as ANT properties). Doing so, nobody would need to invest any effort into such a tedious and error-prone workaround.

Chances for this change are near zero. This is for two reasons:

• ant is not in favor any more, so no one wants to invest into it.
• this is not compatible change, which might impact existing solutions, provided they will upgrade the version.

As a frequent Maven contributor I need to disagree.

• I could do the change on my own, just as I did a lot of times with other Maven plugins in the past, so committers are just bothered for review and voting.
• This is a compatible change as soon as it is opt-in using a new configuration property.

While this is a nice workaround, the actual solution would be to
convince the maven-antrun-plugin to promote the dependency classpath
to ant implicitly (just like it promotes Maven properties as ANT

I’d like to figure out what Saxon is doing that’s not working for you
and see if we can fix that for the next release. I use Maven
(indirectly, through Gradle) all the time and I’ve never had any trouble
resolving the XML Resolver jars.

Something about your environment is different and if I can get a test
case that reproduces it, I might be able to fix it.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

I doubt that there is anything wrong with Saxon itself. The problem is either ANT not forwarding the classpath to the java ant task, or Maven antrun plugin not forwarding the dependency classpath to ANT. I assume it is the latter.

Late to the party but I'm also running into this from the java command line (no maven, just straight java).

• using Java11 (yes, a bit old, but LTS still current)
• using the jar Saxon-HE-11.3.jar

(N.B. This command line works with Saxon-HE-10.5.jar)

java -jar Saxon-HE-11.3.jar -xsl:source.xslt -s:source.xml -o:output.xml

and I get the famous "java.lang.NoClassDefFoundError: org/xmlresolver/Resolver"

I understand from this that I won't be able to use the -jar shortcut with 11.3 but instead I'll have to construct the classpath with multiple jars from the command line.

That's too bad as it was a nice shortcut with a single jar.

That is kind of odd, I am using the Java 11 and Saxon-HE-11.3.jar pretty much like you do and never run into problems related to the resolver.

Hi Alan,

• using Java11 (yes, a bit old, but LTS still current)
• using the jar Saxon-HE-11.3.jar

(N.B. This command line works with Saxon-HE-10.5.jar)

java -jar Saxon-HE-11.3.jar -xsl:source.xslt -s:source.xml -o:output.xml

and I get the famous "java.lang.NoClassDefFoundError:
org/xmlresolver/Resolver"

Where did you get the Saxon-HE-11.3.jar from?

If you got it from our downloads, then when you unpacked it, there
should also be a lib directory next to it. The resolver and a few other
jars are in that lib directory.

If you moved it without copying the lib directory, or if you grabbed the
Saxon Jar file out of some Maven cache, then that’s probably the
problem.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Hi Norman,

I do understand that the xmlresolver jar can be retrieved separately and added to the classpath.

What I'm mentioning and perhaps not conveying is that, whereas one could previously run this command line to run a transform:

java -jar Saxon-HE-10.5.jar -xsl:source.xslt -s:source.xml -o:output.xml

one must now run this other command line (unless I am missing something fundamental, in which case I would be ecstatic to be enlightened):

java -cp "Saxon-HE-11.3.jar;xmlresolver-4.3.0.jar" net.sf.saxon.Transform -xsl:source.xslt -s:source.xml -o:output.xml

Be sure to know that I'm not complaining. I'm an avid saxon enthusiast and evangelist and I appreciate your work more than you probably could imagine.

I'm mentioning this "feature regression" here just so that you are aware that there is an impact on command-line running of Saxon. Im not blocked, but a little sad that, unless I am mistaken, one can no longer run a transform from java with simply the " -jar " flag.

And in all cases, thanks for the help and the good work.

If you install/unzip the HE 11 zip from Sourceforge into some directory on your computer (e.g. C:\Program Files\Saxonica\SaxonHE11J) and then run e.g. java -jar C:\Program Files\Saxonica\SaxonHE11J\Saxon-HE-11.3.jar -xsl:source.xslt -s:source.xml -o:output.xml you can run with the -jar option and Saxon finds its libraries (like the resolver) in the lib subfolder of the installation directory.

Hi Martin,

I appreciate the suggestion.
I'm really looking for the -jar XX.jar solution without having to prepare an unzipped directory beforehand.

The two-jar-classpath solution will work.

Thanks and best regards

-alan

Saxonica Developer Community notifications@plan.io writes:

I appreciate the suggestion. I'm really looking for the -jar XX.jar
solution without having to prepare an unzipped directory beforehand.

I’m confused, Alan. You have somehow obtained and downloaded the Saxon
jar file. If you got that from Maven, the POM file included should point
your system to the relevant dependencies. If you got that from a ZIP
file that you downloaded from one of our repositories, then it will have
included the relevant jar files in the lib directory as Martin suggests.

If you have taken just the jar file (either from Maven or from our ZIP)
and discarded or ignored the ancillary information in the POM file or
the other files in the ZIP, then…well, yes, I guess it won’t work. But
why would you do that?

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Hi Norman,

I'm also a little confused at explaining something that I thought was self-evident but, upon reflexion, I realize that it's perhaps a question of very different work contexts.

Within banks and other hyper-secure environments, one can't download zip files from Saxonica. I also can't plug in a USB stick. Verboten. The bank wants to make sure that no unwanted artifacts make it into the bank's network, hence everything is "vetted" before being brought in. Certain artifacts from maven central, once vetted for vulnerabilities and licenses, are retrieved into internal repositories. Everything that I retrieve is necessarily piecemeal, jar by jar, pulled out of the internal artifact repository. For builds, this poses no problem, because maven/gradle will retrieve all of the dependencies. But there are many instances where I want to run a transformation from the command line outside of a maven project. With Saxon-HE-10.5, I was using "-jar" for that.

An example of a use outside of maven/gradle: When deploying applications with complex configurations, especially with environment-specific and even cluster-specific properties, I'll often use XSLT to generate the various documents (files) that make up the installed configuration. This is typically performed directly in the remote environment which will not have maven/gradle installed. Previously, I could do this by including only the Saxon-10.5.jar with the delivered bundle for remote execution on a deployment platform. Now I'll be delivering other jars with it and making the command line a little bit more complicated.

I've mentioned that it's nothing of a showstopper, but just not quite as convenient as it was previously with a single, self-contained jar.

I was curious about Martin's mention of "java -jar" finding the xmlresolver-4.2.0 jar by itself. I wasn't able to reproduce this in my local environment. Comparing the the Saxon-HE.11.3.jar's manifest from the internal repository and from the Saxon website (using my personal kit), I see that there is a difference: the Class-Path declaration is missing from the internal jar. I don't know exactly why that is .. I suspect that it's another security "feature" that is applied when the maven-central artifacts are retrieved to the internal artifact repository.

So this explains why I was not able to reproduce Martin's automatic discovery of xmlresolver.jar using the "-jar" option within the bank.

Personally, I'm ecstatic that Saxon-HE.11.3.jar has made it into the internal repository, even without the Class-Path declaration in the manifest.

I hope that this clears up the "why I would want to" part, albeit verbosely.

I understand the reason to not bundle everything in the saxon jar, hence I'll have to accept this evolution in my command-line-launched transformations.

thanks and best regards

-alan

I've mentioned that it's nothing of a showstopper, but just not quite
as convenient as it was previously with a single, self-contained jar.

Fair enough. You’re setting up a very bespoke environment so it’s not
surprising that you have to manage the classpath a little more
carefully.

I was curious about Martin's mention of "java -jar" finding the
xmlresolver-4.2.0 jar by itself. I wasn't able to reproduce this in my
local environment. Comparing the the Saxon-HE.11.3.jar's manifest from
the internal repository and from the Saxon website (using my personal
kit), I see that there is a difference: the Class-Path declaration is
missing from the internal jar. I don't know exactly why that is .. I
suspect that it's another security "feature" that is applied when the
maven-central artifacts are retrieved to the internal artifact
repository.

Actually, I just looked and it appears the classpath is removed as part
of publishing it to Maven. That’s not too surprising really since if
you’re using Maven, you expect Maven to manage the classpath for you.
Having random extra changes applied by jar files could definitely make
“classpath hell” even worse.

I hope that this clears up the "why I would want to" part, albeit
verbosely.

Yep. Thanks.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

I'm getting this error when I try to use Saxon 11 in Apache Tomcat 9. Copying the lib/ directory to the same place as the Saxon .jar lets it run from the command line, but not from a servlet.

Tomcat clearly isn't using the classpath manifest in the Saxon .jar. So how do I get Tomcat to notice and use the xmlresolver.jar?

And is there a way of doing so that doesn't involve making two copies of xmlresolver.jar, one for the command line, the other for Tomcat?

Tomcat clearly isn't using the classpath manifest in the Saxon .jar.
So how do I get Tomcat to notice and use the xmlresolver.jar?

A quick search reveals a number of StackOverflow questions about where
to put jar files for Tomcat. It seems to vary by version and other
configuration options, so I won’t try to link to a specific one.

And is there a way of doing so that doesn't involve making two copies
of xmlresolver.jar, one for the command line, the other for
Tomcat?

If you have to put them in /x/y/z for Tomcat, then you can run Saxon
from the command line using the jar files in that location by putting
the jar files in /x/y/z on the classpath explicitly when you start Java.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Michael Brazier wrote in RE: SaxonHE 11.1 (java.lang.NoClassDefFoundError: org/xml...:

I'm getting this error when I try to use Saxon 11 in Apache Tomcat 9.

May we know what version of Saxon are you using? How do you build and package your tomcat application? Do you use maven or Gradle or something else?

Do you package Saxon as part of your WAR file, or put it in the shared lib folder of Tomcat?

I'm using Saxon HE 11.4. I am not using Maven or Gradle. And I put Saxon in the WAR file.

Putting xmlresolver.jar in WEB-INF/lib directly lets Saxon run in a servlet, which solves my problem, at least.

I am having the same problem with 11.4, and in fact, when I try to go back and use 10.5 (which is the version I was using before), I get the same error.

I see that in the download files, there is a folder called "lib" with three .jar files, including two xmlresolver files. Should I drop those files directly into the "Java" folder with my other jar files, or drop the "lib" folder into the Java folder? Is it expecting the path to be /Java/ or /Java/lib?

Kate, you might be better off to start your own question where you describe exactly how you try to use Saxon (e.g. from the command line, the stack trace seems to suggest that), on which platform, where/how you installed Saxon etc. Did you use Saxon 10.5 before successfully and now, after not getting 11.4 to work, 10.5 is failing too? Or are you just starting with Saxon and need some help with that? If you downloaded the zip the installation is usually unzipping all in there to your preferred location, that with put e.g. the Saxon jar and the lib folder with the other jars in the same directory and with that setup Saxon should find the resolver.

Thanks Martin. Yes, I was successfully using 10.5 before, but now neither 10.5 nor 11.4 work. Previously, the Java folder had an Extensions folder with only the saxon-he-test-10.5.jar, saxon-he-10.5, and saxon-xqj-10.5 files in it. So, when I downloaded the new version, those are the files I dropped in (the 11.4 versions). I do not see any indication that the other files in the package (like the files in the lib folder that come with 11.4) were previously located anywhere or necessary.

What environment is that? If you tried to install Saxon HE 11, did you follow the instructions at https://www.saxonica.com/html/documentation11/about/installationjava/installingjava.html saying "Installation of SaxonJ on the Java platform simply involves unzipping the supplied download file into a suitable directory."?

I would start with that approach if the aim is to get Saxon 11 to work as it certainly does not only work with the saxon-he-11.4.jar but will be looking (for most uses) for the lib folder with the xmlresolver-x.y.z.jar and the xmlresolver-x.y.z-data.jar.

As for Saxon HE 10 no longer working, I currently can't tell what causes that, what kind of error do you get there?

I get the same error regardless of whether I'm referencing the 10.5 file or the 11.4 file: *Exception in thread "main" java.lang.NoClassDefFoundError: org/xmlresolver/Resolver * I am using it to split up an XML file into several different XML files. I've updated both OpenRefine (the program from which I export the XML file) and my Saxon version, so the problem could be stemming from either/both.

The command references the JAR file, an XSLT file, and the XML file. I've removed identifying data (within brackets):

java -jar /[location]/saxon-he-11.4.jar -s:/Users/[name]/[folder]/[filename].xml -xsl:/Users/[name]/[folder]/[file-name].xslt -o:file.xml

In my understanding, for Saxon HE, the installation expects you to unzip the complete download into e.g. /[location] (where you now have the saxon-he-11.4.jar file) as that also means the lib directory with the XML resolver and XML resolver data jars is where Saxon looks for it.

So for fixing Saxon HE 11, if you haven't done that already, please make sure that you unzip not only the saxon-he-11.4.jar into that location, but the lib folder that is in the zip as well, also to that location.

The failure of Saxon HE 10 to work, with the same error as Saxon 11, surprises me, I don't know why that happens, I think you will need to wait till someone else shows up that has an idea.