I want to drag a thread of conversation from CXF-2044 to this list. History:
Aegis, since it's inception in XFire, used JDOM as a representation for XML Schema. The classes that represent types were invited to contribute to the schema by directly manipulating the schema in JDom. This was in turn connected to Jaxen, since Jaxen is the provider of XPath for JDom. A motion was made to reduce the dependency on JDom and Jaxen. It came from the D-OSGi folks, who had technical (and, I think, IP) issues with the JDom/Jaxen stuff. So, for 2.2, I wiped out the JDom usage, connecting Aegis directly to XmlSchema. This is consistent with some overall direction in CXF of centering on XmlSchema as a representation for, ahem, XML Schema. It also goes well with Dan and my status as Xml Schema committers and my status of being the only person with the time and strong stomach to work on it at the moment. Brian Relph then reported one of the many rather ugly problems that existed in the JDom-based universe. It's just really hard to ensure consistency amongst multiple XML Schema documents by multiple unrelated classes doing surgery on their individual schemas via JDom. After some consideration on this list, I want ahead and backported that work to 2.1.x. What none of us savored in that discussion is that this: The Aegis API for defining new types is essentially a public API, and now we've got an incompatible change between 2.1.4 and 2.1.5. Pro: ok, we have an incompatible change that effects some number of brave souls who implemented custom types, in return for otherwise hard-to-achieve fixes for everybody. Con: it's incompatible, and, not everyone is happy to find that the tooth fairy has left the XmlSchema API on their pillow overnight. Dan asks if it's possible to offer any sort of half-way house here. I doubt it for any level of effort I'm likely to produce really soon. The Aegis API doesn't just involve the Type building a brand new JDom Element; rather, it is making any number additions to the overall schema document. We have the option of rolling back the port and leaving the bugs. I can't say that I would approach that effort with great enthusiasm, but perhaps someone with better SVN chops than mine could tell me how to do it fairly easily.
