[SDO CTS] M1 Release Plan
Hi, The SDO Community Test Suite has amassed a good number of test cases since we started only a couple of months ago. In view of this, it seems we should think about a milestone 1 release. There are a couple of areas we could improve on so I'd appreciate comments and additional views/insights from the community. There are a couple of pages in the wiki ( http://cwiki.apache.org/confluence/display/TUSCANY/Index) about the SDO CTS, we could do with adding more pages - but I don't think this should gate an M1 release. I was wondering if we should have a number of main suites in the cts/sdo2.1 project. Currently we have the CTSGeneralSuite which includes the DateConversionTest XSDSerialisationTest DataObjectTest and DynamicTypesFromSchemaTestCase test cases classes. This is a subset of the test cases in the cts/sdo2.1 project. I guess there are a couple options. 1. Use a similar approach to the cts/sdo2.1-tuscany project and have Core, Optional and UnderReview suites 2. Group test cases into areas according to the part of the specification they cover. Whilst 2 seems like it could be interesting, I tend to prefer the first approach as I have a feeling that we may just end up with as many suites as test case classes . Alternatively we could just leave the decision to those using the CTS, although this may make it harder for a user (as opposed to an SDO implementer) to run and understand the tests - WDYT ? Comments greatly appreciated - what do you think needs to happen before we cut a M1 release ? Many thanks to Robbie and friends for their contributions to date. All the best, Dan
Re: [SDO CTS] addition of paramatized tests, application server harness
Copy thread back to dist lists On 15/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi Robbie, Was planning to take a look at your recent jiras tomorrow (was a little too busy last week) - I've just created a patch for one of the RW test classes (though may refactor it to follow similar lines to the other scenario tests). So far, I've not needed to use SDOUtil and I'd like to keep it this way 2.1 seems to remove most of the need for it... problem is that any SDOUtil dependent code would need to go into another directory (with separate pom) otherwise anyone building the CTS may inadvertently download Tuscany classes (which is not really desired, IMHO). Cheers, On 15/01/07, Robbie Minshall [EMAIL PROTECTED] wrote: Hey Dan. Should I go ahead and create a patch for the CTS. I think that the biggest issue that should probably be discussed is the additions to,and removal of tuscany implementation of TestHelper. - Should be a seperation similar to spec and impl where the test classes and framework does not rely on tuscany classes like SDOUtil. perhaps something like : java/cts.vendor/sdo21 - Perhaps there should be a refactoring of TestHelper interface so that there is a util class for things that will be common across vendors and things that are very vendor specific like static sdo generation. I will take a look at the rougue wave patch this afternoon. Robbie On 1/15/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Robbie, Dan's the main man on this CTS stuff now. I'll still keep committing stuff when necessary, and chip in if it's appropriate, but I'm not going to get a chance to review your new stuff in detail any time soon. Cheers, Kelvin. On 15/01/07, Robbie Minshall [EMAIL PROTECTED] wrote: Dan, Kelvin have you had a chance to look at some of the changes to the organization and the use of use of junit 4.1 features. Any more thoughts on vendor specific initialization and staitc SDO testing ? If you like the general format of hte paramatized tests then I will spend some time needed to clean it up and create a 'patch' for what is currently in the java/cts branch. If there are suggestions, or especially reorganization issues then lets discuss them. cheers, Robbie On 1/11/07, Robbie Minshall [EMAIL PROTECTED] wrote: I have opened *TUSCANY-1048https://issues.apache.org/jira/browse/TUSCANY-1048 * to track this topic. The initial drop of the cts code had some contributions from Brian Murray and myself. I have made some significant modifications to these which I hope will better fit into the framework. The work is not complete but is complete enough to get some feedback on what features etc would be desirable in the CTS. - Paramatized test suite. Tests API calls and scenarios using Junit 4.1 paramatized test runner to use DataObjects created and populated using different mechanisms - Application Server Test harness and application. Application UI using DOJO to categorize and present errors within a jsp for tests that have been executed within the application server environement rather than within a simple standalone java env. - Use TestHelper which in turn used HelperProvider to get instance of commonj.sdo.helper.* classes. I will attach source to the JIRA and continue this discussion there where appropiate. Robbie On 1/11/07, Robbie Minshall [EMAIL PROTECTED] wrote: I would lean towards providing an exucutable jar file and a structure that allows for vendors to have their own branch/pom.xml for vendor specific implementations ( static code, TestHelperImpl etc ) and a dependancy on the cts ( java/cts/sdo21 java/cts/vendorImpl/tuscany or something). However, I am not sure off the top of my head if that would work well with the surefire plugin for maven. I personally prefer and use ant so will ultmately just be pulling in the cts jar into my own build env. Robbie On 1/9/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I would like to get people's thoughts on how we want to launch the SDO test suite. As you may have seen, an initial set of tests have been committed via jira 987 http://issues.apache.org/jira/browse/TUSCANY-987. Since the tests are the product of the CTS suite, they are in the /src/main/ folder. As I'm sure you know this means that they will be built into a jar when the default mvn build is run. Currently the pom does not actually attempt to run the CTSagainst any implementation. Personally I think this is the right default behaviour, if it was to run the CTS against Tuscany by default it would add a dependency to tuscany and download it - which kind of goes against the idea of being
Making the SDO SCA schemas available via internet
Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan
Re: Making the SDO SCA schemas available via internet
Do'oh what a muppet (I am)... didn't think of that, though the url is not the most memorable, it fixes my immediate concern... thanks Pete :) Anyone from the OSOA collab around who can raise this? Dan On 08/01/07, Pete Robbins [EMAIL PROTECTED] wrote: On 08/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan I think ultimately they should be available from OSOA site. Can you just link into the svn src tree in the tag for the release you are using? Cheers, -- Pete
Re: Build problem (Tuscany M2 SDO) (Linux)
Like others, I thought this sounded like a parser problem... so I tried with a couple of sun jdk levels on my ubuntu linux machine... Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03) Both of them worked ok for me (as do the ibm jdks) How does this compare with your jdk levels ? Regards Dan PS. First time I tried this I forgot to change JAVA_HOME (relying on PATH settings to select the jvm) if you have a JAVA_HOME set it looks like maven will use this jvm regardless of the PATH settings I don't think that the failure to download the Woodstox stax parser causes the problem - this happened when I was running mvn too On 05/01/07, Ron Gavlin [EMAIL PROTECTED] wrote: I suspect you are using a Sun 1.4 JDK which bundles the old crimson XML parser rather than the Xerces parser which is bundled in IBM's 1.4 JDK. I believe EMF (and therefore Tuscany SDO) does not support the crimson parser. I suggest you download and configure the latest Apache Xerces 2.x parser ( http://xerces.apache.org). The Xerces site has instructions for configuring the parser with the Sun JDK. FYI, the Sun 1.5 JDK now bundles a varient of the Xerces parser. Let us know if you have add'l questions. - Ron - Original Message From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, January 5, 2007 1:38:11 PM Subject: Re: Build problem (Tuscany M2 SDO) (Linux) Linux has different vendors, each has different versions. JDK has different vendors, each has different versions configured with different XML parsers by default. Not sure Kelvin and you share the exactly same environment. If a different XML parser worths trying to solve the problem, using IBM JDK may be one of the easy ways. On 1/5/07, Stanislaw T. Findeisen [EMAIL PROTECTED] wrote: Yang ZHONG wrote: Have the build test failures been solved? Many copying/forwarding on the thread... Unfortunetely not. If not, the following looks familiar to me: java.lang.NullPointerException at org.apache.crimson.tree.ElementNode2.getAttributeNodeNS( ElementNode2.java:432) at org.apache.crimson.tree.ElementNode2.hasAttributeNS( ElementNode2.java:388) It might be caused by a parser problem, a newer version or IBM parser might solve the problem. Oh really? Why does it work for Kelvin, though? He says: I have verified that the M2 tag of SDO builds on linux.. And if so -- what should I do? Perhaps the release needs to be fixed, hm? That's because I don't have any crimsons here, so that must be something being downloaded by maven. Kelvin, how did you perform that Linux build? Was that an isolated environment, with an empty CLASSPATH etc.? And what about that wstx-asl-3.0.1.pom? Is it unsignificant? What is it for? -- Leave this world better than it was when you were born. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: General question about Tuscany SDO
Knee jerk reaction says that Tuscany's SDO implementation would work for this however you should remember that Tuscany uses EMF as part of it's runtime. How do you plan to represent the EMF models as SDOs... whould you be trying to generate a set of SDOs from the Ecore schema, or do you have your own model ? You could try running the ECore.xsd through the generator - assuming it works ok then you should be ok Hope this helps Dan On 02/01/07, Łukasz Olek [EMAIL PROTECTED] wrote: At our university we are working on a tool for a group of people. The tool allows to manipulate EMF model, and share it with a team. I am thinking about two approaches: - Pure EMF with sharing files through CVS or Subversion - Apache Tuscany SDO The requirements are following: 1. EMF model stored in one place (server) 2. client can work off-line (disconnect from server) 3. changes are synchronized with server by user's request 4. server can store generic ecore model (the meta-model is not hard-coded into server) We have made basic evaluation of CDO features. It would be perfect, but it doesn't allow to disconnect from server (req 2.) Do you think Apache Tuscany would be appropriate in this situation? Greetings, Lukasz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO CTS] Testing statically generated classes
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
Re: Proposal for a (Java) community test suite for SDO
Hi Kelvin, Thanks for creating the component for Jiras... I agree we need to amend the names to cope with different spec / implementation versions We need to agree on: - SVN module - propose java/cts/sdo2.1 - allow for java/cts/sdo30 java/cts/sca (if needed) in the future - Java package - propose test.sdo21 - allows for test.sdo30 / test.sca.096 (if needed) in the future - How to easily link between test cases (or suite) and sections in the spec - propose package conversion of test.sdo21.section.subsection - eg. package test.sdo21.api.datagraph for tests relating to the Java API (main section) DataGraph (minor section) of the spec (section 3.2) - another eg. test.sdo21.typeconv for the DataTypes Conversion section (section 16) - Using test.sdo21.section.subsection makes it easy to link cases to spec, but might be a little overkill - any thoughts ? - Where to locate SDO 2.1.0 Java Classes - propose linking to tuscany sdo spec project - Link to existing ones in Tuscany (in java/spec/sdo-api), or - package own copy - Framework to use - JUnit or the approach Robbie has, or some other ? - need to ensure sdo implementation is pluggable Now that we have a Jira component (SDO Community Tests) I guess we can start opening up new features against it and identifying what we have - if there is an existing large suit / contribution then we could always just adopt its approach (to start with). Cheers, Dan
Proposal for a (Java) community test suite for SDO
I would like to propose starting a community test suite for service data objects (SDO CTS) implementations written in Java. Based on feedback from an earlier post this seems to be the first logical step in getting interoperable SDO implementations in all languages. I can see this leading to an interoperability test suite to check serialisation between implementations also works (across languages and implementations). Proposal for Community Test Suite (CTS) for SDO Develop a test suite to validate an SDO implementation behaves as expected, according to the community's understanding of the SDO specification. Should the specification appear ambiguous or unclear then the community will decide what to do; it may decide to test the area with an agreed expected behaviour, or decide not to test this area. Ambiguities will be fed back to the specification group for clarification. Although we will run this against Tuscany, the test suite will only test things that we think any implementation should support. The SDO CTS will enable developers to choose or switch SDO implementations without the concern of having to re-code a significant proportion of their application due to differences between implementations. This community test suite will first focus on areas identified important to developers of SDO applications. SDO users feedback and involvement will be crucial to the success of this effort. Over time this may grow to include a large proportion of the SDO specification, however the suite should grow according to the community's desire, rather than attempting to be a validation or compliancy suite. To encourage everyone with an interest in SDO to contribute and use the suite, I propose we : 1. Create a separate module in SVN to separate this from Tuscany components and testcases. 2. Make use of a java package namespace that is not attributable to either Tuscany or any other SDO implementation: test.sdo 3. Refactor some of the existing Tuscany SDO Java test cases to remove any Tuscany specific coding and re-package these to the test.sdo namespace. 4. Accept tests from anyone who wishes to contribute them under normal Apache contribution conditions. SDO users involvement will be crucial to this effort, developers of SDO implementations will benefit by contributing to and consuming a community test suite, rather than working on their own. Who's up for working on this with me ? If you are interested in joining this effort; have any concerns, comments or suggestions please append them... Thanks in advance to all those who volunteer :) Dan
[SDO] Hello rfc for what could be useful
Hi All,I would like to help out on the Tuscany SDO effort, so though I'd pop out a quick note to see what's what.There are a couple of things that might be desirable to the community, so I'd appreciate your comments on what's needed: Interop / TCK for SDO - make sure one SDO behaves the same as another (useful for testing the -noEMF flag)Eclipse plug-ins for SDO - make it easier to generate / use SDOs in an IDE environment SDO DAS generation - generate DAS config/classes for SDOs (similar to https://issues.apache.org/jira/browse/TUSCANY-898 but possible to use without SCA also, unless I'm reading this jira wrong)I have already written some of the eclipse plug-ins (see attached pngs). There are a couple minor changes needed (adding the jars using the plug-in registry, rather than classpath vars) I need to work out how to get Maven to build it - but other than that they work and I'd be happy to contribute them, assuming they would be of use... Thanks in advance for your commentsDan Murphy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO] Hello rfc for what could be useful
Hi Simon, Interop testing with PHP, C++, etc was certainly one of the things I was thinking of... The way I see it is that the tests could be run in a number of different modes: serialiseSDOs - serialise SDO object to file system so they could be loaded by different impl deserialiseSDOs - load SDO objects from serialised useDynamicSDOs - programatically generate SDO using APIs useGeneratedSDOs - generate SDOs from schema and use the generated ones to run tests I see serialise/deserialise option used to test interop between different implementations of SDO - esp interop between implimentation languages. The useGeneratedSDOs only makes sense with Java implementations (as I understand it Java is the only one to generate simple objects to represent SDOs). All the tests would need to cover the features descriped in the spec (or agreed subset), for the serialise/deserialise tests to work there would need to be shared SDO descriptions used - eg. C++ serialises a customer and Java deserialises it and checks the SDO is as expected). I'd be happy to work on the Java side, my C++ is rather poor so together I think we could make some progress together - if the interop is needed... as you say, would be a poor show if (complex) C++ serialised SDOs couldn't be read by the Java impl... Cheers, Dan
