Well, the way I've done it is to do a sed parsing of files to find
invocations of "new SqlException". This is inherently a brittle
approach because it isn't using the real semantics of Java to figure
this out. So if somebody writes something a little different, things
get munged up.
The rea
Hi David,
How volatile is this test and how hard to fix it when it breaks? Can
mere mortals help out here? Do you think that, with a little more work,
it's feasible to drop this into the nightly test run some day? I'm not
speculating about who might want to scratch that itch, just wondering
h
The problem with running it as nightlies is that it is liable to fail at
compile time when new messages are added -- I regularly have to update
the sed script to adjust for these new messages. I would hate to have
the build fail because of this.
If you have any ideas, let me know, but that wa
David Van Couvering wrote:
There's a test I'd like to see run as part of release verification.
[snip]
This involves a lot of substitution work, and each time new
SqlExceptions are introduced, it tends to require some tweaking
[snip]
I could run this test myself as part of my validation of
There's a test I'd like to see run as part of release verification. It
is a sanity check for internationalized messages to make sure that we're
actually loading and creating messages correctly. It can't be run as
part of derbyall because it requires some code generation, it depends on
GNU sed
