So, as Andrew very astutely pointed out, i18n/MessageBundleTest.java
will not succeed when running against the jar files because it tries to
load shared/common/reference/SQLState, which is not included in the jar
files. This problem also exists for MessageId.java, which this test
also refers to and which also is not included in the jar files.
After some thought, this can be solved in three ways:
(1) put SQLState.class and MessageId.class into derbyTesting.jar
(2) at build time, run a tool that builds a test class that contains all
the message ids in SQLState.java and MessageId.java
(1) would definitely be easier, but I just can't be sure whether this is
kosher. In one way, you can argue, hey, if you need a class for
testing, it's OK to put it there. This is a white-box test (e.g. it
depends on internal classes), to be sure, but it's an important one
(2) is a backup solution if for some reason (1) is not kosher.
Your comments most appreciated! If there is no feedback, I'll go with
(1). I would make *very* clear comments in build.xml why this is going
on, by the way.
Thanks,
David
