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: Modular build, was: VOTE: Approach for sharing code
Date Wed, 21 Sep 2005 04:04:49 GMT
This proposal was based on the assumption that our common code would 
*never* be exposed to the outside world.

I also never claimed that we should apply this solution to third-party 
components.  That's a fish I don't think we need to fry right now.

I think you are probably unhappy with this solution because it goes 
against your vision of a modular architecture for Derby.

If you don't assume that any "module" of Derby can go with any other 
version of any other module, but instead assume that all of Derby goes 
together as a single unit, then it's fine if the client and engine code 
for a given version are tied to the common code for the same version. 
It actually makes sense -- you have well-defined and predictable 
behavior in an unpredictable environment where multiple versions live in 
the same classpath.

If you aren't thinking modular, I personally don't think it's that 
arcane and confusing, particularly compared to making multiple copies of 
an original "common" class.

I also can't think of any other solution besides class cloning (which I 
really dislike) that can solve this problem and still give us common code.

David

Jeremy Boynes wrote:
> I find this arcane and confusing; worse, I don't think it really works.
> 
> Code that is using the common API becomes tied to a specific version. By 
> renaming the package we force all users of the common code to modify 
> their code. We can do that for things in our source tree but not in others.
> 
> Similarly this forces us to modify any external libraries we use to 
> exhibit the same behaviour - for example, renaming o.a.commons.logging 
> to o.a.commons.logging_1208. This means we have custom versions of all 
> external libraries.
> 
> Think of the carnage if it was java_14208_b13.sql_300.Connection
> 
> -- 
> Jeremy
> 
> David W. Van Couvering wrote:
> 
>> Hi, all.  I've been letting this brew in my subconscious this weekend, 
>> with the strong belief that *somehow* there is a solution that can meet
>> all of our requirements (simple architecture, ease-of-use, 
>> compatibility, no regressions, easy to maintain, reduce code 
>> duplication).
>>
>> I think I may have something that will do this, and your comments are 
>> much appreciated.  There is a bit of overhead for the release process, 
>> but I think if we are going to have overhead, that's the place to do it.
>>
>> The principle is that for each release, the common package is unique. 
>> This is achieved by appending the release number to the package name. 
>> So for the 10.1.2 release the package name is org.apache.common_1012. 
>> In this way a consumer of the common classes for a given version is 
>> guaranteed to load the right classes and no conflicts or confusion occur.
>>
>> As part of the release process, when you make a branch for a release, 
>> you run a script that renames the common package to match your release 
>> name.  This script does the following:
>>
>> - In the source, replace all instances of 
>> org.apache.common_<oldversion>  with org.apache.common_<newversion>
>>
>> - Do an svn move of java/common/org/apache/common_<oldversion> to 
>> java/common/org/apache/common_<newversion>
>>
>> Because you are using svn move, although it's a bit confusing, all 
>> history is maintained and you can still use svn to do merges and ports 
>> of changes.
>>
>> The common package is put into both derby.jar and derby-client.jar, 
>> and we do not create a new JAR file.
>>
>> Thanks,
>>
>> David
> 
> 

Mime
View raw message