db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Tue, 13 Sep 2005 23:21:32 GMT
Admittedly I approach this mostly from an app server perspective, but I 

--Create a common package and put all common code there
--Make a separate jar with this stuff in it
--Leave the common classes out of derby.jar and derby-client.jar
--For users convenience in standalone apps produce an additional jar 
that includes everything from common, derby, derby-client, network, 
drda, etc etc.  This would not be used if you are concerned about 
classpaths and versions or the smallest possible footprint.
--Make sure that all the jars have clear version numbers in their names.

I think you are asking for major classloader trouble including the same 
classes in 2 different jars (doesn't this produce a sealing or signing 
problem?) and I think the package-name munging approach is really ugly 
and twisted.

david jencks

On Sep 13, 2005, at 3:34 PM, David W. Van Couvering wrote:

> Hi, Kathy, thanks for your email.  The timing is actually pretty good, 
> I was just talking with Francois trying to understand his concerns 
> better.
> After quickly describing the two approaches, I'd like to summarize the 
> experience/impact of these approaches from the perspectives of the end 
> user, the developer/maintainer, and the test developer/runner.
> Goal:
>  - Reduce code duplication while continuing to support different 
> versions of client and embedded driver in the same VM
> Approach 1:
>  - Create a common package and put all common code there 
> (org.apache.derby.common)
>  - Use compatibility guidelines to ensure backward compatibility and 
> some degree of forward compatibility
>  - Common classes are embedded in derby.jar and derby-client.jar 
> (based on lots of negative feedback for having a separate jar)
> Approach 2:
>  - Create a common package and put all common code there 
> (org.apache.derby.common)
>  - During build process, "clone" all common classes into at least two 
> generated packages, one for the engine and one for the network client 
> (org.apache.derby.engine.common and org.apache.derby.client.common).  
> - This approach avoids having to implement compatiblity 
> guidelines/constraints and guarantees, as the engine and client 
> continue to be fully isolated
> Approach 1
>  - No new jar files, everything looks the same
>  - For the vast percentage of users who don't mix versions in the same 
> VM, everything works great
>  - For the small percentage of users who mix versions, the order in 
> which jar files are loaded.  For example, if they want to use 
> derby-10.2.jar and derby-client-11.0.jar, then if derby-10.2.jar is 
> first in the classpath, they will get an exception saying that the 
> client code is incompatible with the common code and that they need to 
> re-order their jar files, whereas it will work fine if the order is 
> reversed.
> Approach 2
>  - No new jar files, everything looks the same
>  - Ordering of jar files does not matter, everything works fine
> Approach 1
>  - Pretty much as it is today, nothing surprising
> Approach 2
>  - When navigating code either during source browsing or debugging, 
> they will see the *generated* common code, not the master common code.
>  - If a developer is not aware of how things work, or just forgets, 
> he/she will try to edit this generated code, and will be confused and 
> surprised when his/her changes disappear after a build
>  - Stack traces will point to generated code, and the developer will 
> have to remember to translate that back to the master version.
>  - The generation process must be very careful not to adjust line 
> numbers or all stack traces will be off and misleading.  This means 
> for instance we can't add comments saying "THIS IS GENERATED CODE, DO 
>  - We may need to generate more copies if different types of version 
> mixing are required (e.g. if the tools.jar and derby.jar need to be at 
> different versions)
> Approach 1
>  - We would have to build and run compatibility tests to make sure 
> that compatible versions run correctly and incompatible ones correcty 
> raise the exception
> Approach 2
>  - No real change, although debugging of tests may be confusing due to 
> issues I already listed under developer experience
> I also am uncomfortable with the "twistiness" of approach 2.  There is 
> something to be said for a clean architecture and build environment.  
> I have seen time and again that a good architecture allows you to 
> scale and grow, whereas "twisty" architectures tend to wrap you up and 
> tie you down at some point.  I think this has to be taken into 
> consideration.
> My main question is: is it OK to sometimes throw an exception for the 
> small set of users who mix versions, and for them to then have to 
> rearrange their jar ordering.  If the answer is that this is not 
> acceptable and would be considered a showstopper regression for some 
> part of our user base, then I think we have no choice but to go with 
> Approach 2, even if we do risk painting ourselves into an 
> architectural corner.  Otherwise, it is my strong recommendation to go 
> with Approach 1.
> Thanks!
> David
> Kathy Saunders wrote:
>> David W. Van Couvering wrote:
>>> Well, we're at a bit of a standoff here.  What I'm looking for is a
>>> nail-in-the-coffin data point that would move us in one direction or
>>> the other.
>> I've been following this discussion with some interest as my 
>> background is technical support.  In fact, I supported Cloudscape for 
>> the first 4 years (from release 1.0 of Cloudscape).  My experience is 
>> that developers (particularly Java developers) really liked 
>> Cloudscape (now Derby) because it was so easy to use and deploy.  
>> And, I found historically that one of the most common issues to come 
>> up were classpath issues (in particular we got in trouble a few times 
>> when we introduced something that caused the order of the jar files 
>> to be important).  You should note that I'm not, and never have been, 
>> a Derby developer, so I don't claim to be an expert on what's correct 
>> and best from a development perspective.
>> I'm a bit concerned because I see a lot of discussion about what is 
>> good from a derby development perspective, but not so much how these 
>> changes may affect users of Derby.  Although some Derby users have 
>> complex applications (like application servers), many are 
>> implementing much more simple solutions.
>> Having said that, I'm a bit lost in what is being proposed from the 
>> user/functional perspective.  David, as soon as you have a more 
>> concrete proposal (may not be the time yet), can you post that 
>> information?  Could you  provide information on what the users of 
>> Derby will have to do with this change (how would our documentation 
>> need to be changed) and maybe footprint, performance, etc. impacts 
>> vs. the benefits  from making this change.  I'd like to be able to 
>> provide my input from a usability/documentation perspective.
>> In addition, I work on Derby now in the testing area, so I'd also 
>> like to understand the implications for what additional testing might 
>> need to be done.  If we create more jar files, is there more testing 
>> requirements for different combinations?
>> Thanks,
>> Kathy
> <david.vancouvering.vcf>

View raw message