Ron, many thanks for your response; it's really helpful to get your suggestions. We certainly intend to make use of a significant body of tests that exist in Tuscany.
I can open up another thread to specifically call out for an understanding of users' dependencies on a) the Tuscany API we have added to deal with gaps in the 2.1 spec, or add-on features, and b) any instances where users may have gone in under the covers themselves to make use of EMF features, but I guess I'd really hoped for that to come out of this discussion. So I'd like to see whether your posting begins to spark a bit more feedback on this thread before doing that. Your proposals for priorities for Apache SDO are very much appreciated, and I'd be interested in helping the community to achieve some or all of these goals. Kelvin. On 11/02/2008, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > 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] > >
