Christian Grün wrote:
Hi,
The error seems to point to an automatically generated class, which contains a string with (way) too many characters. Good to know that everything works with "mvn compile", so I'll currently leave it like that for now..
Ok. FWIW, it seems extracting them as external files or resources should be enough.
Out of interest: could you try switch to your test directory and run the tests from there? This is probably what most of us do. To be honest, I'm not even sure if someone in the team uses the -p flag at all, although I mentioned it to you in one of my last e-mails.
A bit weird... For what I've seen in the source code, the test suite directory is either set by "-p", or fixed to "g:/XML/w3c/qt3ts/" (static variable QT3TS.qt3tsPath). Because the base URI is not properly set for files in environments defined in the global catalog, they are resolved against the PWD. So the only way to have them resolved, if I am right, is anyway to be in the test suite directory and either to have it at "g:/XML/w3c/qt3ts/" (on a Windows filesystem only) or to use "-p ."
I've tried "-p ." and it works. Thanks!
FWIW the line 236 in QT3TS (b = null;) looks suspect to me. It sets the base URI to resolve files in environents to null (only for envs defined in the global catalog.xml).
I guess that Leo's XQuery FOTS code (or a slightly enhanced version of it) could be adapted much easier to other implementations, as most of the code is written in pure XQuery 3.0 [1].
Yes, this is a good candidate! (even though at first glance it uses map{}, so is restricted to XQuery 3.0 + Map Facility implementations). BTW the goal is not to have one test harness for all implementations, but to be sure that all implementations are able to run FOTS-based test suites ;-)
Thanks for your response. BaseX is definitely one FOTS-ready processor! ;-)
Regards,
-- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/