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: domain of mcintyre.a@gmail.com designates
 64.233.162.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=G4mBbsBLVBDQxCnIYWPvE20a9o4RuW3SKl4qSwtBVVAQytmouQ8Y4msTJJ2nXGwyiEGCefscGSQS5o8S9Pc8dP7PZfjrrnUayugg7RMUL7dYLZ5ScfDX5H3jrq24Q1QYNKc1d1HzbY0QNy2DzubMHme5cW/IbxkUJ79cyfzDw5E=
Message-ID: <54ac72d705091614086c4bff62@mail.gmail.com>
Date: Fri, 16 Sep 2005 14:08:37 -0700
From: Andrew McIntyre <mcintyre.a@gmail.com>
Reply-To: mcintyre.a@gmail.com
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Modular build, was: VOTE: Approach for sharing code
In-Reply-To: <432B2F83.4030205@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <431F8896.605@sun.com> <4325E2E2.8010503@sun.com>
	 <43274D95.6050808@mtrad.com> <432753D9.5090808@sun.com>
	 <432857C9.6050908@mtrad.com> <43287189.3070001@debrunners.com>
	 <4328DF41.4040508@apache.org> <43299E2E.50006@sbcglobal.net>
	 <54ac72d7050916132037efa112@mail.gmail.com> <432B2F83.4030205@sun.com>

On 9/16/05, David W. Van Couvering <David.Vancouvering@sun.com> wrote:
> I appreciate your pragmatic approach, Andrew.  The thing is I have seen
> a number of other pieces of functionality queued up for code sharing
> between client and server.  These include DRDA network code, potentially
> some higher-level JDBC functionality, logging and tracing, and
> management via JMX.  I also discovered that the versioning mechanism in
> org.apache.derby.iapi.services.info is actually reused across tools,
> client and engine.

This is true, I realize that there are a lot of opportunities for code
sharing and reuse. I just don't know if *this* is the one that is
worth it. I think the way these possible code-sharing opportunities
should all be handled is for someone to implement some new
functionality as a module and package it into a new *optional* jar
file. The new code can be used if it is present, and the old code can
be deprecated, but remain packaged for a certain number of releases
before it is removed, if it is removed. This gives users time to
prepare for a change and developers to work through all the issues
without causing any unnecessary pain along the way.

Do we really want to go to this trouble for the client localization
functionality? I don't know. To me, logging seems like a better first
project for that.

> We may still decide this is intractable and throw up our hands, but I
> hope that's not the case. It's been a healthy debate, and has brought
> to bear some good discussions about "who" we want to be, what our key
> principles are, and I think that's been good too.

I agree, it's been a good healthy debate, but I thought it might be
good to reflect upon the task at hand. :-)
=20
> You talked about signing/sealing problems about packaging the classes in
> multiple jars.  I saw this mentioned before, can you or someone else
> elaborate?

When a jar is sealed, classes cannot be loaded from multiple if the
package they are in is sealed. You can unseal specific packages, so
that's less of an issue than for signed jars. I believe attempting to
load the same class from different jars if the jars are signed will
cause a SecurityException, but I'm not well versed in the ins and outs
of signed jars.

andrew