I have converted our other test cases to junit 4.1 and am in the process of doing some cleaning up etc. Will send out a quick update tonight and can integrate into tuscany if needed.
* * * Whether the CTS should test static SDOs (I believe so) ? * * * Optional means to supply static class generator and/or previously generated static classes would be good. As a note we are moving our test cases to use a generator task rather than checking in previously generated classes - just is not working right now so we checked in manually generated classes for the shortterm. ? What is the outlook for spec group clarifying static SDO generation ? ? Should there be any backwards compatability requirements for static SDO generation for tuscany implementation ( tests would not be contained within CTS ) ? * * * Whether Maven'ize the SDO CTS is desired ? * * * I would imagine that the Tuscany community would like this mavenized. Currently I just work simply using ant. I was imaginging that one would provide a build.xml or pom.xml with an example configuration for an implementation ( tuscany would make sense since that is where this is getting hosted ) and other vendors could simple update with configuration for their implementation. Other vendors could supply their own maven plugins if necessary and we could provide a general plugin which invokes listed generator class with command line style arguments. If using ant then classpath can be setup in xml file and vendors can provide their own or edit appropiately. Robbie On 12/20/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
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]
-- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
