Paul Mossman wrote: > Damian wrote: > ... >> Go for it. > > It is done. (Revision 17044.) > > >> Although I have to say that after some problems we had with >> XML unit on IBM JVM Kevin and I were on the verge of removing >> it entirely in favor of simple String comparisons. Some tests >> were randomly failing and we never found out way. Kevin lost >> couple of days chasing it and then it stopped as inexplicably >> as it started. > > When was this? We were updated to the latest IBM JVM a few months ago, > so things might be better now. (Hard to tell though if the problem > isn't reproducible.) > > >> Especially if you run the tests in Eclipse side by side view >> works much better than cryptic XPath expression telling you >> where the problem is. > > To me the big advantage of an XML compare is that you don't need to keep > expected and generated character-for-character synchronized. > > The problem output will be a lot more useful now. (Part of what I > needed xmlunit-1.3 for.) Suppose the generated file contains an > unexpected Polycom property. Previously you would only see: > > [different] Expected number of element attributes '13' but was '14' - > comparing <SIP...> at /sip[1]/voIpProt[1]/SIP[1] to <SIP...> at > /sip[1]/voIpProt[1]/SIP[1] > > Now you will also see: > > [different] Expected attribute name 'null' but was > 'voIpProt.SIP.use486forReject' - comparing <SIP...> at > /sip[1]/voIpProt[1]/SIP[1] to <SIP...> at /sip[1]/voIpProt[1]/SIP[1] >
That's indeed better. Thank you. I fixed Eclipse configuration and I created an issue to track this update (XX-6917). Please always use the issue number when committing in sipXconfig directory. Thanks again, Damian _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
