Xerces-J is packaged as a ZIP file for all platforms and operating systems. The parser release is also packaged as Tar GZip files as a convenience for UNIX users. You can extract the ZIP files using the Java jar command to unpack the distribution.

	jar xf Xerces-J-bin.2.7.1.zip jar xf Xerces-J-src.2.7.1.zip jar xf Xerces-J-tools.2.7.1.zip

All of these commands create a sub-directory called "xerces-2_7_1" in the current directory, except for the command to unpack the "tools" distribution, since you may install this anywhere you like.

In order to accomodate the very common case in which Xerces is used with an XSLT processor such as Xalan, between Xerces 2.0.0 beta 3 and beta 4 a change in the default organization of Xerces' jar files was introduced. As well as the xercesSamples.jar file, which we still produce, Xerces formerly came with a file called xerces.jar. This file contained all of the parser's functionality. Two files are now included: xercesImpl.jar, our implementation of various APIs, and xml-apis.jar, the APIs themselves. This was done so that, if your XSLT processor ships with APIs at the same level as those supported by Xerces-J, you can avoid putting xml-apis.jar on your classpath.

Should you wish to use the xerces.jar instead, we have included several Ant targets for backward compatibility. An "Ant target" is an argument given to Ant, our build tool, that tells it which portions of the build.xml file to apply.

If you are on a Windows system and you wish to get only the xerces.jar file, you would execute build.bat deprecatedjars.

If you want to regenerate new versions of the Xerces binary, source and tools distributions with the old-style jarfiles, you would execute build.bat deprecatedall. The situation is analogous for Unix users, except that build.sh would be used instead of build.bat.

For further information and more options, please look inside build.xml itself; all possibilities are documented there.

In order to provide security-conscious users with the best possible assurance that the Xerces distribution they have downloaded is official, "signatures" are provided for all 6 Xerces packages produced in each release. A signature is produced with cryptographic software (such as PGP or GNUPG). The cryptographic software is used to apply an algorithm that uses the secret "key" of a Xerces committer to generate a unique file from each Xerces distribution. The Xerces committer then makes a "public" key available, which the user can use, in conjunction with the downloaded distribution and the accompanying signature, to verify that the distribution was actually produced by that committer.

In order to verify the legitimacy of Xerces distributions you download, these steps should be followed:

1. Get a copy of PGP or GNUPG from the above URL's.
2. Obtain the signature of the Xerces package you wish to verify. For instance, if you want to verify the legitimacy of Xerces-bin.x.y.z.tar.gz, download the Xerces-bin.x.y.z.tar.gz.asc file from the same location as the original file was obtained.
3. Obtain a copy of the public key of the Xerces committer. While most committers have posted their keys to public "key servers", probably the easiest place to get them from is CVS. The public keys of all Xerces committers who post releases are available from the file called KEYS located in the root directory of the xml-xerces/java repository.
4. Add these keys to your "public" keyring. In GNUPG, you'd do this with a command like gpg --import KEYS.
5. Issue the command for verifying signatures appropriate for the cryptographic software you've chosen. For GNUPG, this would be gpg --verify Xerces-J-foo.x.y.z.ext.asc Xerces-J-foo.x.y.z.ext.

Note that, in general, it won't be necessary to acquire new copies of public keys to verify signatures for each Xerces release. This will only be necessary if a new Xerces committer has published the release.