There are a number of folks who have mentioned they are depending on the
code sharing framework to move forward with their work. In particular
the JDBC 4 exception subclass work depends on the exception framework I
put together for client exceptions. Also, Francois' encryption work
includes shared code and he is waiting on the framework as well.
The classloader work I am doing to avoid code shadowing bugs in a mixed
version environment is going well, most tests are passing but there are
still some corner cases I have to work out. I am thinking a week before
I submit a patch, and then I expect (and rightly so) that this will go
through a few weeks of review.
I was wondering if in the meantime I can unblock those who are waiting
for me by checking in the code sharing framework *without* the
classloader work. This would be with the solemn promise to submit the
classloader work soon thereafter, and definitely before the next patch.
If for some sad reason the classloader stuff gets a -1, we can revert to
the somewhat more ungainly feature-management functionality I had
submitted a month ago and which looked like it was moving towards
acceptance. If that doesn't pass muster, we can revert to generating
copies of the shared code with separate package names for each jar file
(as Kathey suggested). So I think regardless of what choice we make
there, the shared code can still be written and placed under the
org.apache.derby.shared package hierarchy. All that would change would
be how this shared code would ultimately be packaged into jar files.
Is this acceptable? If so I'll go ahead and clean up the i18n and
error-handling shared code and get it submitted so folks can move forward.
Thanks,
David
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
