Also see the XMLC 2.2 Release Note, XMLC 2.2.1 Release Note, XMLC 2.2.2 Release Note, XMLC 2.2.3 Release Note, XMLC 2.2.4 Release Note, XMLC 2.2.5 Release Note, XMLC 2.2.6 Release Note, XMLC 2.2.7.1 Release Note, XMLC 2.2.8.1 Release Note, XMLC 2.2.9 Release Note, XMLC 2.2.10 Release Note, and XMLC 2.2.11 Release Note.
Added the ability to specify a resource path to provide extra classpath information to the <xmlc/> task allowing XMLC compile-time access to XCatalog and DTD resources on the classpath. Previously, one had to specify a file system path to get the XMLC compile to work, but then modify the XMLC metadata and XCatalog files to point to the classpath at runtime. This change unifies compile-time and runtime lookup of resources. For example...
<xmlc ...> <resourcePath> <pathelement location="${resources}"/> </resourcePath> </xmlc> OR <xmlc resourcePath="${resources}" .../> OR <path id="xmlcResources"> <pathelement location="${resources}"/> </path> <xmlc resourcePathRef="xmlcResources" .../>
Just to be clear, classpath URLs look like 'file:/org/mypackage/resources/custom.xcat' or 'file:/org/mypackage/resources/custom.dtd'. Though these look like file system URLs, XMLC's XMLEntityResolver strips the leading 'file:/' and looks these up on the classpath. Without configuring the resource path, XMLC will only be able to look up resources in the classpath provided to the taskdef for <xmlc/>, which should only be used to provide the XMLC and XMLC taskdef jars (and any other dependencies) to load the task itself. The classloader's classpath is manipulated only temporarily while in use by XMLC. It is then restored to its original state before exiting the task so that the classloader is not polluted for uses external to the current <xmlc/> task invocation.
See the org.enhydra.xml.xmlc.taskdef.Xmlc javadoc for more details and at least one caveat.
It is now possible to use XMLC on the command line without a batch script or adding a bunch of jars to the classpath. This was accomplished by adding proper META-INF/MANIFEST.MF information, incuding Main-Class and Class-Path and XMLC version information. Other than the main jar (xmlc-base.jar, xmlc.jar, or xmlc-all-runtime.jar), dependent jar names must be non-versioned, and found in the same directory as the XMLC jar, in order to be found on the claspath. For instance, use "gnu-regexp.jar", not "gnu-regexp-1.1.4.jar".
Additionally, I've made it so that javac compilation is supported without having to provide the XMLC "-classpath" option. It is created automagically for you if it doesn't exist. If the "-classpath" XMLC option does exist, but doesn't contain the main XMLC jar, the XMLC jar will be appended to the classpath for you. It probably makes more sense to simply not provide the option since it is not required. Note that this only applies to running using "java -jar xmlc-base.jar", not standard invocation using "java org.enhydra.xml.xmlc.commands.xmlc.XMLC".
Along the same lines of the addition to the Ant task above, special care needs to be taken to resolve custom resources such as XCatalogs and DTDs on the classpath. If you don't use the "-xcatalog" XMLC option, you can ignore this info. It's a little ugly, but it can be done by putting resources in the same directory (in whatever package you desire) as the XMLC jar (and all other jar dependencies). In order to allow for this, I had to avoid using the INDEX.LIST feature of jars because it causes the classloader to ignore the "." I added to the Class-Path in the MANIFEST.MF. I'm not aware of any way to allow for user defined classpath information without manually modifying MANIFEST.MF to suit one's individual needs. So, if you use "-xcatalog" a lot, you might want to go the batch file route instead of using the "java -jar" option.
Up to now, XMLCVersion only reported the major version, 2.2. As of this 2.2.12 release, it will report "2.2.12". Then again, this information can also be obtained via the now fully specified jar manifest information: "Implementation-Version".
Added explicit license information to the XMLC build root (about time, no?). It contains the LGPL license and describes how the LGPL supercedes any files in the source claiming to be EPL (Enhyda Public License). This file is now added to the root of the generated XMLC jars.