Re: ADVICE REQUESTED: Fixing MessageBundleTest
Hi David, You might want to wrap the test in a custom Ant Task. These are described in the Ant manual: "Developing with Ant"->"Writing Your Own Task". You can then check the return status of the task and fail the build if appropriate. Regards, -Rick David Van Couvering wrote: Hm, a build-time check. I guess in a way it is a build-time issue. Let me think about how I might do that, thanks for the idea. David Daniel John Debrunner wrote: David Van Couvering wrote: 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. Does this need to be a test, could it be converted into a build time check? Then there are no requirements for these classes to be in derbytesting.jar. Also there is probably no requirement to run this test on different platforms. I used to have something similar (pre-open source), that found messages that existed but were never used. Dan.
Re: ADVICE REQUESTED: Fixing MessageBundleTest
Hm, a build-time check. I guess in a way it is a build-time issue. Let me think about how I might do that, thanks for the idea. David Daniel John Debrunner wrote: David Van Couvering wrote: 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. Does this need to be a test, could it be converted into a build time check? Then there are no requirements for these classes to be in derbytesting.jar. Also there is probably no requirement to run this test on different platforms. I used to have something similar (pre-open source), that found messages that existed but were never used. Dan.
Re: ADVICE REQUESTED: Fixing MessageBundleTest
David Van Couvering wrote: > 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. Does this need to be a test, could it be converted into a build time check? Then there are no requirements for these classes to be in derbytesting.jar. Also there is probably no requirement to run this test on different platforms. I used to have something similar (pre-open source), that found messages that existed but were never used. Dan.
ADVICE REQUESTED: Fixing MessageBundleTest
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