Yes, you've got it right Jim. One thing that we did overlook, in terms of priority, was that generated classes can't use any EMF features, even in their impls. We initially put together a generator that generates EMF-less interfaces, but had EMF things in the implementation classes. That solves the problem of hiding EMF from clients, but we overlooked the fact that the generated classes are in the client's jar, so the client still needs direct access to EMF :-)
One of the things that we had planned to do as a longer term exercise was to decouple the generated classes from EMF, but now I've bumped it up to my personal #1 work item. I hope to get an initial version of this working in the next 2 to 3 weeks. Now back to the issue of whether or not to use SDO for the SCDL model. Personally, I think that the main issue Jeremy is bringing up is that the way SDO is currently being used for a Java binding of the physical model, which then needs to be transformed into a different logical model, really makes one question its value. You need to write similar code to create the logical model, whether it's by reading from StAX or from the generated physical model API. The generated API is a little nicer, but hardly enough to warrant the added layer/complexity. I think I agree with that. But, if I step back, I really question the need for two models in the first place. If I understand the history of this, the goal was to have a logical model to hide the physical model, and specifically, the EMF complexity it contained. If that's true, and given my comments above about the EMF-less code that we're planning to generate, I would think that the right end goal is to unifying the logical model with the generated model, instead of eliminating it and writing all the model building code by hand. I think that we really should use the Tuscany code generator. It is important that it be a competitive Java binding technology (as good or better then JAXB, etc.), so what better way to make that happen then to use it ourselves. The SDO spec is pretty vague on what an SDO generator actually generates (other than the fact that the interfaces are bean-like), so we have a lot of opportunity to provide options, etc., to make it do exactly what we want. That's my admittedly biased 2 cents worth :-) Thanks, Frank. Jim Marino <[EMAIL PROTECTED]> wrote on 03/22/2006 02:53:53 PM: > My recollection - Frank let me know if this is incorrect - was that > the SDO impl would not necessarily be "EMF-free" but that it would > hide implementation details. For the Java runtime, the goal was to be > "EMF-free" from the perspective that the runtime would not contain > direct dependencies on it. > > Jim > > > On Mar 22, 2006, at 1:15 AM, ant elder wrote: > > > On 3/21/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > <snip/> > > > > We have been working to remove the dependencies on EMF > > > > > > Is a goal to have an EMF free SDO impl? One of the reasons I liked > > this STaX > > based approach is it makes the Tuscany core look more lightweight, but > > removing the EMF dependency could also help there. > > > > ...ant > > >
