Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 14 Sep 2005 20:36:52 -0700
From: "David W. Van Couvering" <David.Vancouvering@Sun.COM>
Subject: Re: Modular build, was: VOTE:  Approach for sharing code
In-reply-to: <4328DF41.4040508@apache.org>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <4328EC54.8000707@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_yx7HKjOb5+Lso81xP4JbBA)"
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
References: <431F8896.605@sun.com> <43207ABC.8080000@sbcglobal.net>
 <43208918.8050706@debrunners.com> <4321049C.2080701@sun.com>
 <4321DF25.1070302@apache.org> <4321E124.7000403@sbcglobal.net>
 <432205BF.604@apache.org> <4325E2E2.8010503@sun.com>
 <43274D95.6050808@mtrad.com> <432753D9.5090808@sun.com>
 <432857C9.6050908@mtrad.com> <43287189.3070001@debrunners.com>
 <4328DF41.4040508@apache.org>

This is a multi-part message in MIME format.

--Boundary_(ID_yx7HKjOb5+Lso81xP4JbBA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT


Jeremy Boynes wrote:
[snip]

> Daniel John Debrunner wrote:
>
>> The issue is that today this is fully supported because the client and
>> engine do not share code.
>>
>> Some of the code sharing approaches regress Derby in this area by not
>> supporting this, or require class path ordering for it to be supported.
>>
>
> Some of the others support this by defining compatibility contracts 
> and eliminate the need for classpath ordering by not duplicating classes.

Can't you have the situation where common 10.2 and common 10.3 are both 
included in the classpath (by accident, as Dan brings up)?  Wouldn't you 
end up with order dependencies then?

[snip]

> Let's recharacterize this a little. What we are contemplating with 
> code sharing is extracting common functionality out into a library. By 
> saying that we are not willing to accept any solution where a 
> component depends on a library we are shutting ourselves off from 
> using any external library or any functionality not provided by Derby 
> itself. This dooms us forever to reinvent any functionality that could 
> be provided by other projects.
>
> For example, there are libraries out there that support bytecode 
> generation, JMX for management, high-performance concurrency on Java 
> 1.4, regexp processing to support SQL patterns, ... By saying we are 
> not prepared to incorporate them but instead need our own versions 
> that can be morphed for client and server we dramatically reduce the 
> functionality that can be made available to users.
>
> So let me ask this: do our users want more functionality faster by 
> allowing the use of libraries, or a completely standalone solution 
> with tight control over the entire implementation?

You make a compelling argument here.  I already would like to use stuff 
in Jakarta Commons (I haven't brought it up yet, one thing at a time).  
It seems a good Apache Java citizen should make use of what's in Jakarta 
Commons rather than build stuff themselves.  And I think Jeremy's right 
that we will run into this same configuration situation with these guys.

Jeremy, how *do* the users of commons avoid accidentally using a version 
they are not compatible with (e.g. a consumer depends on new features 
that aren't available in an older version of the common jar file)?

David

>
> -- 
> Jeremy


--Boundary_(ID_yx7HKjOb5+Lso81xP4JbBA)
Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=david.vancouvering.vcf

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@sun.com
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard


--Boundary_(ID_yx7HKjOb5+Lso81xP4JbBA)--