Re: ADVICE REQUESTED: Fixing MessageBundleTest

2006-06-22 Thread Rick Hillegas

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

2006-06-21 Thread David Van Couvering
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

2006-06-21 Thread Daniel John Debrunner
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

2006-06-21 Thread David Van Couvering
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