It's a good time to take stock of where we are and where we want to go with SDO for Java. Clearly there's work to be done with heading towards an implementation of the SDO Java 2.1 spec [1,2,3], but what else might we do; where do you want to take things?
[1] the new 2.1 spec .... http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 [2] For those with a good knowledge of the 2.1 spec you can see what's changed here .... http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL_changebars.pdf?version=1 [3] And for a brief digest of the changes see here ... http://osoa.org/download/attachments/519/SDO_2.1_Features_Nov_2006.pdf?version=1 Does anyone have any bright ideas about value add features that they'd like to suggest and ideally implement? While the spec work is all well and good, I'm sure there are people out there who have said "It would be really neat if ..." Please feel free say it out loud by posting to the list. On the other hand, more tests/samples are always welcome. Similarly documentation. For my part I've been thinking about the new spec element for compliant change summary serialization, and I plan to put some ideas on the wiki soon. In addition to the 2.1 work, we have a stack of JIRAs that if anyone is feeling so inclined would be great to reduce. I've taken a scan through to see which might have a low bar of entry, in that the skills required are general skills rather than SDO implementation knowledge. Please feel free to scan them yourself if you feel you'd like more of a challenge. Alternatively, as I have a reasonable grasp of the current JIRAs, if there are skills you have to offer, I could probably tell you reasonably quickly where they might be applied. If there's any maven experts out there TUSCANY-313 is a good candidate. Same goes for TUSCANY-901and 902. Similarly some discussion on how we might structure our code to take account of the fact that the Interface2JavaGenerator class has a Java 5 dependency, yet the rest has a 1.4.2 + prereq would be good (TUSCANY-257). Maybe someone could attack TUSCANY-303, where the Java generator can only handle a single namespace to package mapping, and this needs to be extended to a list of such mappings (I'm not sure how deep that one gets into the generator itself, but may be some investigation might result in a partial patch ) Tuscany 578 is a bucket defect for recording occasions where we throw the wrong type of exceptions, while not very exciting, it might be a good candidate for someone to experience the process of submitting a patch to an open source project for the first time. I would have thought that the new feature TUSCANY-893 wouldn't be too onerous -- if you take a look and want to discuss it on the list that would be great. And of course I don't wany to denigrate you, the Tuscany community's skills. I'm sure there are those of you out there who are quite capable of diving into some of the other issues, but like I said, these are the ones that don't require you to get your head round much of the Tuscany Java SDO implementation. Please don't be shy. If you think you can help we'd love to hear from you. Regards, Kelvin.
