On 4/7/06, Bryan Pendleton <[EMAIL PROTECTED]
> wrote:
Myrna van Lunteren (JIRA) wrote:
> I was thinking of adding a property, say, generateUTF8Out, into RunTest, which would create an additional file, <testname>.utf8out.
Are you proposing that there would be another entire set of
master files in the tree to store and maintain?
Or are you proposing that these new master files would be
dynamically and automatically generated on demand?
There would only be the master files we have now. They have been, for the most part, created in UTF-8 compatible encodings - that, however, is because we have all been working in an en_US.UTF-8 centric environment.
The history of this issue goes back to a discussion in re DERBY-575: http://www.nabble.com/proposed-modification-current-test-harness-%28Re%3A-DERBY-575%29-t382261.html#a1054996
I repeat what Dan said:
" There is the problem of test development on such a [non-ISO-8859-1] platform, either for new tests (and test cases) or for platform specific masters. [The new comparison] scheme
will result in the master output being in an encoding that cannot be checked into the codeline, or copied into them master directory, since it is not in ISO-8859-1.
Maybe it can be worked around by the developer switching between using
ISO-8859-1 and the default on that platform.
The other risk is that a cannon will be checked into the master directory that is not ISO-8859-1 encoding, since someone is runing tests on such a platform. "
Maybe it can be worked around by the developer switching between using
ISO-8859-1 and the default on that platform.
The other risk is that a cannon will be checked into the master directory that is not ISO-8859-1 encoding, since someone is runing tests on such a platform. "
I have a really hard time envisioning the situation Dan described, because I have a hard time thinkng how one would develop sql and java sources etc. with svn on such a platform. Do those files show up in UTF-8, i.e
. unreadable? Or does svn convert text files so you can still read them on each encoding?
I can see, however, a situation where the encoding is slightly different from 'what the rest of us' use, so that for the most part, all files are readable and even the tests currently run - mostly. But there would be occasional characters that are different and cause troublesome failures.
Note, also, that all this supposedly becomes mute with .junit tests.
Either way, that concern of Dan's is what this new property is trying to address.
I thought it would be sufficient to have it only implemented in a limited way - only for individual tests (not suites), and only settable on the command line (not in properties).
This is how it would work: someone working on a non-ISO-8559-1 system would develop (code/tests) and run tests like normal, and find that a new master is needed for a specific test. The developer would then rerun that specific test with the property:
java -DgenerateUTF8Out=true org.apache.derbyTesting.functionTests.RunTest blah/blah.sql
This will, in addition to what we have today, create a .tmpmstr in the local encoding (like is already done for network server) which is what will be used to compare the .out file (also in local encoding, like today), *and* a .utf8out file that is the ISO-8559-1 version of the .out. That utf8out file is not used in assessing whether the test passes or fails, but is the .out file read back in and then out in UTF-8. The developer working in this non-ISO-8559-1 encoding would then use *that* utf8out file to be copied as the new master .out file in the svn source tree.
For the rest of us working on ISO-8559-1 systems nothing would change, and there'd be no reason to run with the generateUTF8Out property.
Myrna
