I think the CTS should test static SDOs, but maybe it should be a separate optional part and maybe even a lower priority to focus on.
As you point out, the SDO spec doesn't define how generators work, how static metadata is registered, or even how to create instances statically - according to the spec, the only way to create instances would be dynamically with DataFactory.create(MyStaticType.class). Given all the missing details, it will be hard to write static tests that test that much and are also not Tuscany specific. One thing that may be good is to just provide a mechanism for someone to plug in static implementations of one or more of the models used in the dynamic test suite, allowing them to run the same dynamic tests against their statically generated implementation classes. Frank. "Dan Murphy" <[EMAIL PROTECTED]> wrote on 12/20/2006 10:48:27 AM: > Hi, > > Integrating Robbie's code (jira > http://issues.apache.org/jira/browse/TUSCANY-987) highlights a general > problem for testing statically generated types. For example, statically > generated classes using Tuscany's SDO M2 implementation are not compatible > with the current SDO implementation (in this particular case the > org.apache.tuscany.sdo.model.impl.ModelPackageImpl no longer exists). > > Further, the specification does not specify how to generate static classes > from schemas (it does specify what the resulting classes should looks like, > but not how to actually invoke the generator). One option would be to have a > maven task that invokes an implementations static generator prior to > compiling the code that depends on it, however this doesn't resolve all > probems. > > With Tuscany it is necessary to register static type via the > SDOUtil.registerStaticTypes(staticFactory.class) or other method pending > jira http://issues.apache.org/jira/browse/TUSCANY-684. Presumable this is > also necessary with other implementations. > > I'd appreciate people comments on : > Whether the CTS should test static SDOs (I believe so) ? > This would mean we'd need to be able to delegate to different > implementation static class registration mechanisms (some form of > adaptor/abstraction layer) > Whether Maven'ize the SDO CTS is desired ? > How best to allow different implementations to be selected in the pom > would be interesting > This would also require additional maven plugins to allow different > implementation generators to be invoked or additional steps in the pom to > directly invoke different generators > If not maven we could automate with different ant scripts for different > implementations (or have "users" edit a general ant script) > The downside of this is that the ant script would need to know the > location of the implementation JARs > > I hope we'd all agree on the first point, but I think the second two could > open up some interesting discussions. > > Many thanks in advance, > Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
