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 Re: svn commit: r370815 [1/2] - in /db/derby/code/trunk: ./ java/build/org/apache/derbyBuild/ java/client/org/apache/derby/client/am/ java/client/org/apache/derby/loc/ java/engine/org/apache/derby/iapi/error/ java/engine/org/apache/derby/iapi/reference/ ja...
Date Fri, 20 Jan 2006 18:23:32 GMT
Yes, I came to the conclusion that the whole feature management 
framework was just too complex and error-prone.  I am of the strong 
opinion now that any solution we come up with for shared code should not 
rely upon backward/forward compatibility guarantees and associated 

I think we have two good possibilities, one we know that works but is a 
bit unintuitive (the code copying solution proposed by Kathey) and the 
classloader work (which I have working for the most part but which does 
add complexity to Derby).  If the classloader solution is not 
acceptable, we can fall back to code copying.  Although any solution put 
forward will need to go to a vote.


Andrew McIntyre wrote:
> build works now, looks good. Thanks, David!
> On Jan 20, 2006, at 9:01 AM, David W. Van Couvering wrote:
>> This was based on feedback by Dan from my last patch, that having  the 
>> common stuff at the top level was a bit of a bug; it's better  for 
>> each "shared component" to have its own package (e.g.  shared.drda, 
>> shared.common, shared.security, etc.).
>> I should update the Wiki page to reflect this.
> A second read through package.html made it a bit more clear. The  
> contents of shared.common are meant to be 'truly universal' whereas  
> other subpackages of shared may not be.
> Also, are the CommonFeatures/Info classes going away with the  
> classloader work? I noticed they were also absent with this patch.  
> (Sorry if that's also in a previous mail, I'm having trouble  searching 
> my mail at the moment).
> andrew

View raw message