db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Modular build, was: VOTE: Approach for sharing code
Date Fri, 09 Sep 2005 19:14:45 GMT
David W. Van Couvering wrote:
> I thought Kathey/Dan's idea of generating copies of the common code
> into two separate directories was interesting and solved a lot of problems,
> and I thought it would be worthwhile to walk through this in a bit more
> detail.
> 

This seems like a lot of build time complexity for very little benefit. 
We are doing all this pre-processing (in source or, please no, in 
binary) just to avoid the need for users to include two jars on the 
classpath instead of one.

This is also reinforcing Derby's not-invented-here attitude that 
requires implementation of everything rather than using libraries freely 
available from other open source projects.

I'd like to crack this discussion wide open and say that we should move 
away from the one-jar-to-rule-them model and switch to a model where the 
different components inside Derby can be built and versioned 
independently and where we are comfortable depending on external 
libraries to provide core functionality.

In that context, components that come to mind are engine, client, net, 
tools and common and external dependencies for consideration include 
logging, configuration and thread management.

I would like to discuss moving to a modular structure where these are 
built separately and can be released separately. That gives us the 
benfits of simplicity, shared code, and reduced maintenance without the 
wierdness of code templates and preprocessing.

For users that want one single jar, we can merge them togther either by 
combining jars or through the use of Class-Path references in the 
manifests. But that should be a special distribution rather than the norm.

--
Jeremy

Mime
View raw message