I think consolidating the two SDO implementations under a single implementation would be good for the entire Apache SDO community. My concern would be that no Tuscany SDO features be lost in the transition. The new implementation should provide most of what I can currently achieve using both EMF and Tuscany SDO. For example, EMF features like integrated validation should be available in the new implementation before the old implementation is dumped. It might be a good idea to poll the Tuscany SDO community to identify the EMF features currently being used by Tuscany SDO community. It might also be interesting to poll the Eclipse EMF SDO 1.0 community and ask the same question. Maybe many of the existing Tuscany SDO test cases could be re-written for either 1). the new implementation or 2). the CTS, to minimize the loss of functionality during the transition.
>From my perspective, the priorities for Apache SDO moving forward should be: 1. Align Apache SDO with the JAXB specification. The static SDO implementation should be JAXB-compliant. 2. Align Apache SDO with the JPA specification. It should be simple to use a OpenJPA to persist SDO graphs. 3. Provide data binding support for popular Java open source WS stacks, especially Axis2 and CXF. - Ron ----- Original Message ---- From: kelvin goodson <[EMAIL PROTECTED]> To: Tuscany Users <[email protected]> Cc: tuscany-dev <[EMAIL PROTECTED]> Sent: Wednesday, February 6, 2008 5:12:03 AM Subject: [Cross Subproject Discussion] options for SDO Java in Apache [I'm cross posting to tuscany-dev and tuscany-user again, to be sure all the Tuscany community sees this. Please use"reply" rather than "reply-all" so that we keep responses to the user list, to help make following the thread easier and continue to reach the wider audience] Some of you may be aware that I'm involved taking SDO Java through the Java Community Process (JSR 235) to achieve standardisation for SDO Java. One of the things that this standardisation requires is that a reference implementation (RI) and technology compatibility kit (TCK) be produced alongside the specification document. To satisfy the RI and TCK requirement we've been constructing a proposal to Apache to create a new incubator podling [1] to do RI and TCK development of JSRs related to SDO. To date the proposal suggests that development of the RI would be best done separately from Apache Tuscany, primarily because developing an RI requires an environment that can focus on the Java interface as specified, and in Tuscany we do cross language SDO, SOA and we encourage innovation outside the spec. I did some digging and questioning to find out if developing a JSR RI in Apache was feasible, and it is, there are examples. However, from the feedback were getting to the proposal it's clear we should be thinking more creatively about how the Tuscany SDO Java community and its aims overlaps with the aims of the new proposal. This has got me thinking now that perhaps we could have a discussion about whether we, the Tuscany community, might like to take the opportunity to be part of establishing a common home for SDO Java development in Apache. A significant thing to consider is that, if you take a look at the proposal [1] you'll see that as part of the JSR agreement, the responsibility for creation of the RI belongs to BEA, and the RI would be created using an initial donation of code from BEA of an SDO implementation. The RI would not be based on the current Tuscany SDO Java. So at this point Apache has two implementations, Tuscany's EMF based implementation, and the new code base seeded by BEA. I'd like to try to understand how the Tuscany community feels about all the aspects of transferring the general responsibility for developing SDO in Apache to a common SDO project. What do you think we, as part of the wider Apache community, would do with our two implementations? How much do you care about what technology underpins an implementation? Would you come and be a community member in the new project? [1] http://wiki.apache.org/incubator/NoNameYetProposal Regards, Kelvin. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
