Well, I would love to move the client jar building to use the
classlister, but it will take me some time to get my hands around this
functionality. I have a stack of Very Important (in my itchy world)
things to get done -- can you give me a sense of how timely this issue
is? I'm assuming it isn't an issue until we try to release something.
Not that I will forget it, just trying to prioritize.
As a temporary fix, isn't there a way to check sanity state in build.xml
and only add SanityManager in a sane build?
Apologies for not understanding the impact of adding SanityManager
directly to the client jar.
Thanks,
David
Andrew McIntyre wrote:
On 3/16/06, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] writes:
AM java/shared/org/apache/derby/shared/common/sanity/SanityState.java
I thought SanityState.java was generated in the build process. Should
it really be in the repository?
No, it shouldn't. I've removed it. Otherwise, jar builds will always
end up with always with M (modified) in their version string.
I also have a problem with adding SanityManager to the insane client
jar file. This means that we probably have to move to using
classlister to build the client jar, but whatever it takes,
SanityManager should not be in the insane client jar.
David, can you fix this?
andrew
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
