Ayla Debora Dantas de Souza - Projeto Ourgrid wrote:

Hi,

in our existing JUnit tests regarding CDL resolution we usually consider all the resolved CDL, because we think it is interesting to test resolutions in the configuration part too, although they may not be used in the System part.

I propose to return the cdl:cdl document in the resolve operation to explore more situations on the tests, but if you think just the system verification is enough, ok. In fact just considering the first child of a system is not good.

I think my resolution process can be fairly destructive on the configuration parts. Also, I only try and resolve stuff under system...other bits of the configuration I may or may not process. Since how we do that is out of scope of the spec, I dont think we can test it,

Just another point: I did not understant what you meant by 2. we retrofit the system wrapper to all existing CDL tests.

Yes, I realised that that was not needed. I thought I'd have to wrap everything under<ct:resolved> in a <cdl:system> element, but that is needless, I can leave that alone. What I do have to do is assume that the response coming back from a resolve() operation is a cdl:system element, and compare all the stuff underneath. Have you tried using the test code yet? I must apologise for making lots of changes to it this week; it has been pretty unstable and one I make this next change everyone's code will have to change. Then I need to sit down and fix the failures that it is correctly showing up... -steve

Ayla Debora Dantas de Souza - Projeto Ourgrid wrote:

Hi Steve,

we have seen the test code, but have not started using it yet directly. So, from our part, feel free to change it, but please let us know when you finish these more recent changes so that we can use it avoiding rework.

OK. I think I have nearly finished. I've inevitably broken Jun's test run, so once we have that working as well then we could say things are stable. More changes -comparisons skip over xmlns declaratations -more context in error messages -added the <cdl:system> wrapper to every response (this was the easiest way of handling responses of >1 element in parallel) -fixed some quirks related to no namespace elements in xerces having a 'null' localname The main thing I've done is delve into the depths of junit and work out how it generates tests from methods, and have written the code to automatically turn every test document from a test catalog into its own test method, with its own success and failure. This is very nice for reporting; here is proof that the tests are successfully catching resolution failures in my code http://people.apache.org/~stevel/reports/org/smartfrog/test/unit/sfcore/lang... The goal for february will be to get the failure rate in this test suite from 100% to 0. as an aside, this is the first time that I've used the DOM java APIs for four years, I had forgotten how awful they are -they dont treat namespace declarations as special -you cant have an element or attribute outside a document -non-namespace behaviour != namespaced element behaviour -painful walking through children -so painful trying to create a parser, what with java endorsed directories. -etc etc. I would strongly discourage anyone from using it in their real code. JDom and Xom are both much better. Remember, Dom was originally written by netscape for javascript's use; then the w3c committees took it and defined it in IDL, C++ and Java. It predates xmlns, and it shows.

Another point, I always have problems trying to run the ant commands from the cddlm repository because everything is always missing in my machine and than I give up. I wanted to know what are the requirements for running the "ant all" or "ant test". I have ant 1.6.5, maven 2.0 and java 1.5. The current error I have is "Unable to find typedef schemavalidate". Do you know what may be missing?

you need an ant1.7alpha release: http://people.apache.org/~stevel/dist/ If its just the <schemavalidate> task (and it probably is), I could tune the build file to not bother validating xsd if the task is not found. As long as gump does it every night we can keep track on invalid documents without doing it every build.