It strikes me that Castor JDO may be at a cross-roads. It appears to suffer
from its heritage of being an early implementation of JDO that has not
totally embraced the latest spec. I imagine that as commercial products and
other open source projects mature in this space, Castor JDO may become
increasingly marginalised.
However, I think that an open-source O-R mapper is of tremendous value to
the Java community at large. It would be disappointing to see Castor
disappear (or stagnate which is possibly worse), especially as many of the
annoying problems of O-R mapping have been solved (but still no collected
polymorphism).
There is are compelling reasons for making Castor fully JDO compliant. In
fact, it should be possible to also support the ODMG interface which is
shockingly similar to JDO (by no coincidence I imagine). Some thoughts that
might stimulate some discussion:
Would it be possible to merge Castor with the JDO Reference Implementation?
Should Castor JDO continue as is?
Should an attempt be made to have Castor accepted as *the* JDO Reference
Implementation (as with Tomcat)?
Should an "OpenJDO" project be started to provide a JDO compliant Castor?
Should a clean-room "OpenJDO" be built from scratch and hosted on
SourceForge?
--Andy Hull
Internet communications are not secure and therefore the Barclays Group
does not accept legal responsibility for the contents of this message.
Although the Barclays Group operates anti-virus programmes, it does not
accept responsibility for any damage whatsoever that is caused by
viruses being passed. Any views or opinions presented are solely those
of the author and do not necessarily represent those of the Barclays
Group. Replies to this email may be monitored by the Barclays Group
for operational or business reasons.
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
