Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/22/2006 09:41:46 PM: > Jean-Sebastien Delfino wrote: > > > > The logical model is actually pretty close to the model generated from > > the XMLSchema. If you take the model generated from the schema and add a > > few derived /calculated relationships and derived attributes you get a > > reasonable logical model for the runtime configuration. > > > > We had this for some time - and contrary to what you're saying here > > Jeremy - it worked. The issue at the time (and it's still an issue now > > but Frank is working on fixing that) was that the generated model had > > dependencies on EMF and some of the EMF aspects were shining through the > > model. This made using this model and in particular writing test cases > > difficult for people without EMF expertise. To workaround this problem > > and shield people in the group from the EMFness of the generated model, > > we created two separate hierarchies, a POJO based model (with no > > dependencies on EMF or SDO), and a generated model (and obviously we had > > to write the code to transform one into the other). > > > > When we get from Frank a code generator that generates EMF-less model > > classes then I think we'll be able to get back to what we had a few > > weeks ago, which again worked... > > - a generated model - always in line with the schema, without the burden > > of writing, debugging and maintaining the parsing code > > - derived logical relationships and attributes (when necessary) in > > subclasses > > - but this logical model will be a POJO model similar to what we have > > now without any EMF dependencies. > > > > When we get there, most component implementation types and binding types > > should actually be able to work with just the generated model classes, > > without writing any code at all (no loader, no parser). > > > > I'll reiterate what I said before, I think that the right strategy here > > is to use our databinding technology, and through that exercise help > > make it better. > > > > I actually said that "it never *really* worked" which is a different > thing. Of course it "worked" as we were able to load configurations; > however, for all of the reasons *you* describe above it was never an > easy-to-use or easy-to-maintain implementation. That is still the case. > > We now have a new level of complexity in that, due to changes to the SDO > code generator *required to comply with the SDO spec* we now have a > whole new set of SDO-specific annotations that had to be added to the > schema files and which now need to be maintained. What next - a new Jeremy, I think you're blowing this one way out of proportion. The issue is simply one of "." characters being used in names. I think the proper solution will be to have a generator option (or default) that will fix invalid Java names during codegen (not the SDO property names during XSDHelper.define - which is what the annotations do). To make the Tuscany SDO code generator competitive, we need to do that anyway. Regardless of what the spec says, a Java generator that generates Java that doesn't compile in some situations is just not going to fly. We will fix it.
> Maven plugin to run the schemas through an XSLT as the SDO spec suggests > in order to mix in our annotations? > > We still don't have a solution to SDO's classloader issues (again, spec > related), we still don't have a solution for loading complex properties, > and we are dependent on future changes to code generation to make it > "really work" at all. > > We've struggled for months with this type of solution, and pardon my > frustration, but when is enough enough? > > -- > Jeremy Earlier in the thread you said this: > We could enhance SDO to handle this mapping better (e.g. through a more > sophisticated code generator). I think we would be better served though > to direct that energy into improving the SDO-centric features of our > implementation rather than doing something special for Tuscany's loading > problem. I'm absolutely convinced that the problems you're describing are not unique to the SCA use of SDO. From my experience with the SDO 1 implementation at Eclipse, I can tell you that as many, or more, people are interested in using SDO as an "XML binding technology" than as a "unified API for accessing heterogeneous data, etc.", so we NEED to make it work well for this. You also said this: > If SDO could de-serialize directly into our logical model then that > would be a simple option to use. However, if the price we need to pay to > achieve that is a heavily annotated XML schema or a custom code > generator I think we are back to where we are now. This MUST BE the end goal, IMO. We just need to accept a few (not so small) bumps in the road on the way there :-) Frank.
