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
