Hi,
how that I have finally (sic!) managed to remove the
JDO[Class|Field]Descriptor(Impl) class(es) completely (by switching to
natures for access to JDO-specific properties of a class/field
descriptor), it is time to focus a bit more on the XML side of things.
Ideally, I'd like to go about the same business.
a) remove XMLClassDescriptor and XMLFieldDescriptor from the code base, and
b) move all this XML-specific data to new XML-specific natures.
Technically, this is not a problem, and can be done with a few hours
investment (and some more hours integration testing). Problem is that
there's no easy way to go about this, as the XMLClass- and
XMLFieldDescriptor classes are exposed globally, as any descriptor
generated through the Castor XML code generator relies on the current
XMLCLass- and XMLFieldDescriptor(Impl) implementations.
Given that, and taking into account that I am not keen on breaking this
user contract, I think it's time to implement a parallel universum and
switch to this new universum at a well defined point in time.
As far as I can tell, this should be straight-forward, as with a Cstor
release to be defined, internally the new classes can be used anyhow,
and externally Castor from then on supports old and new
XMLClassDescriptor instances. And with that very same release, we can
amend the code generator to produce classes living in the new universum
only.
Before going about this, I'd like to hear opinions. Have I missed
anything ? Is there a better approach that I have overlooked ?
Regards
Werner
PS There's a bit of refactoring that could be applied to the existing
XML[Class|Field]Descriptor classes, as well as to the descriptors as
generated by the code generator, where the generated classes (to some
degree) redefine methods declared in XMLClassDescriptor(Impl) anyhow.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
