Re: svn commit: r386187 - in /db/derby/code/trunk: ./ java/build/org/apache/derbyBuild/ java/engine/org/apache/derby/iapi/services/sanity/ java/shared/org/apache/derby/shared/common/i18n/ java/shared/org/apache/derby/shared/common/sanity/ tools/ant/p

[Andrew McIntyre <mc...@gmail.com>]

On 3/16/06, Knut Anders Hatlen <Kn...@sun.com> wrote:
> davidvc@apache.org 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

Re: svn commit: r386187 - in /db/derby/code/trunk: ./ java/build/org/apache/derbyBuild/ java/engine/org/apache/derby/iapi/services/sanity/ java/shared/org/apache/derby/shared/common/i18n/ java/shared/org/apache/derby/shared/common/sanity/ tools/ant/p

["David W. Van Couvering" <Da...@Sun.COM>]

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 <Kn...@sun.com> wrote:
> 
>>davidvc@apache.org 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