db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Submitting shared i18n/error code separate from classloader work
Date Fri, 06 Jan 2006 21:46:40 GMT
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.



View raw message