You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2006/03/14 01:27:56 UTC

SanityManager in shared package

I'd like to use SanityManager in the 'shared' package hierarchy.

Options are:

- Cut-and-paste, but this means having two SanityState.tmpl files, which 
seems odd.  However, it would be the safest.

- Put into the shared package and have both engine and client jar files 
pick up the same class.  This is basically shared code, and comes with 
the related potential shadowing issues.  But perhaps SanityManager is 
stable enough this is not an issue?

What are your thoughts on this?

Thanks,

David

Re: SanityManager in shared package

Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:

> OK, sounds good.  I can't see what the issue would be either, since
> compatibility is only an issue for released jars.

I think this is ok.

The only issue I see is that someone might see it as a precedent and
start importing hither and yon.
Ideally the insane build would be able to catch inappropriate imports
where classes will get duplicated in the release jars. I know of several
cases where such imports have been caught on review and at least  one
where  they actually got committed.  Unfortunately, currently our build
and tests don't catch this.

Kathey








Re: SanityManager in shared package

Posted by "David W. Van Couvering" <Da...@Sun.COM>.
OK, sounds good.  I can't see what the issue would be either, since 
compatibility is only an issue for released jars.

I am *hoping* to get this solved soon, but I have higher priority itches 
to scratch right now.

David

Andrew McIntyre wrote:
> On 3/13/06, David W. Van Couvering <Da...@sun.com> wrote:
> 
>>I'd like to use SanityManager in the 'shared' package hierarchy.
>>
>>- Put into the shared package and have both engine and client jar files
>>pick up the same class.  This is basically shared code, and comes with
>>the related potential shadowing issues.  But perhaps SanityManager is
>>stable enough this is not an issue?
>>
>>What are your thoughts on this?
> 
> 
> Well, since the SanityManager isn't included in the insane jars, thus
> not included in the public releases, and isn't used in the client at
> all, I wouldn't think it would be a problem to just move it over. You
> might want to get a second opinion on that, though.
> 
> andrew

Re: SanityManager in shared package

Posted by Andrew McIntyre <mc...@gmail.com>.
On 3/13/06, David W. Van Couvering <Da...@sun.com> wrote:
> I'd like to use SanityManager in the 'shared' package hierarchy.
>
> - Put into the shared package and have both engine and client jar files
> pick up the same class.  This is basically shared code, and comes with
> the related potential shadowing issues.  But perhaps SanityManager is
> stable enough this is not an issue?
>
> What are your thoughts on this?

Well, since the SanityManager isn't included in the insane jars, thus
not included in the public releases, and isn't used in the client at
all, I wouldn't think it would be a problem to just move it over. You
might want to get a second opinion on that, though.

andrew