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 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
