Orbit/Xerces in Eclipse
Xerces and XML in Eclipse
The purpose of this page is to document various aspects of using Xerces in Eclipse. It's not always easy, and this pages is far from complete, but hopefully will be the start. Others are welcome to document here tips they kave learned, or suggest changes in the the wasy we bundle xerces (via but reports usually).
Parts of Xerces
Xerces, as delivered by Apache, has about 4 or 5 jars in it's distributions that are planned to be part of Orbit. For example, in Xerces 2.8.0:
So far we have done nothing with 'samples', though hope to someday.
API and implementation packaged together
In the Europa Version of Orbit, for Xerces 2.8, we delivered the apis and implementation in one bundle, and the resolver in another bundle, since the resolver can be used outside of Eclipse as a standalone jar to do certain catalog and resolution functions, so we didn't want to lose that capability.
There was one new jar added to Xerces 2.9.0, for improved serialization code (improved especially in that they "merged" the code base between Xalan and Xerces). So, beside the above 4 jars, there is also now a
We have left that separate for now, apart from implementation, simply because there's some class loader issues with it on some VM's, so it deserves more study.
API and implimentation packaged separate
Also, in Xerces 2.9.0 in Eclipse/Orbit, we have left separate the API jar and the IMPL jar. More needs to be done, but the idea is that most clients can "depend on" only the API bundle and if the IMPL bundle happens to be there, then fine, though in principle there could be another implementation present to do the work in some slightly different way, for example. The idea being that client code should not have to change, just to use a different implementation ... as long as they code to the APIs only.
The API bundle codifies what's called JAX-P, version 1.3 in Xerces 2.9. In theory, and there's been some non-urgent requests, this API bundle could itself be divided into three parts, one for the SAX API, one for the org.w3c API, and the remaining JAX-P API (which would require and re-export the other two). That way, if someone knew they only needed a few few APIs, say to do some small SAX processing, then they could have a very tiny pre-req.
- When done right, it should not matter what VM is running, but, it does, so I suspect something is wrong with the way I've set up the manifest files, but will still look into. (The current xerces bundle for 2.9 seems fine on 1.5 and 1.6 VMs, but I've seen some tests fail on 1.4 VMs ... whereas the 2.8 bundle worked on all three levels ... but, not entirely all the same function was tested).
- The largest issue is to research and understand the reason why OSGi spec's specify a special way to register and get the various implementations of parsers, etc. This is above and beyond what Xerces itself recommends, so ... needs to be better understood.
Features and Xerces
The main point of list the parts of Xerces was to motivate why it's necessary to pay attention when creating features to include Xerces. For Xerces 2.8, there's only two to include to get the whole Xerces distribution.
<plugin id="org.apache.xerces" download-size="0" install-size="0" version="2.8.0.qualifier" unpack="false"/> <plugin id="org.apache.xml.resolver" download-size="0" install-size="0" version="1.1.0.qualifier" unpack="false"/>
<plugin id="org.apache.xerces" download-size="0" install-size="0" version="2.9.0.qualifier" unpack="false"/> <plugin id="org.apache.xml.resolver" download-size="0" install-size="0" version="1.2.0.qualifier" unpack="false"/> <plugin id="org.apache.xml.serializer" download-size="0" install-size="0" version="2.7.1.qualifier" unpack="false"/> <plugin id="javax.xml" download-size="0" install-size="0" version="1.3.4.qualifier" unpack="false"/>