Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mcintyre.a@gmail.com designates
 64.233.162.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WCldSdWtFeP8Lwi/FdkQWmHV5qM0VstU74iQysVbfheuBCj+okU51Ft8rrCq92eH5jzEyeqNGDi+rSd/LaneUtet00VpHeStmNRxVj/0QNUugJD4nsNJWSh6Xg/ZiUlScECUn+a1SmK8+9LDSG+f1SlaphC4nATkr2J045jcohE=
Message-ID: <54ac72d70606090112q4277179coc343f9025437d957@mail.gmail.com>
Date: Fri, 9 Jun 2006 01:12:18 -0700
From: "Andrew McIntyre" <mcintyre.a@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby
 client and engine
In-Reply-To: <4488CC94.2000302@sbcglobal.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2165408.1149801030648.JavaMail.jira@brutus>
	 <4488BED3.4030309@sbcglobal.net> <4488C0DF.7020500@sun.com>
	 <4488CC94.2000302@sbcglobal.net>

On 6/8/06, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
> David Van Couvering wrote:
>
> > Kathey.  When you say the "code is copied and modified as needed"
> > what exactly are you thinking of here.  Is this byte-code
> > modification, or are you proposing a source-code copy/modify.  If the
> > latter, wouldn't this require also modifying all classes depending
> > upon the shared classes to use the new package name?
>
> Sorry, missed this one.  Yes I am talking about a source code modify and
> yes some tool would have to modify at least  all the  source that
> imports shared classes and copy all the source over  to production/java
> to be built to production/classes and then put into the jars.  This
> would only need to happen once before the final derbyall run and
> checkin.  During normal development  you can point to the classes and
> not be impacted.
>
> I had originally proposed this step just be an alternate build target
> for nightly and release builds, so developers would not be affected at
> all, but Dan brought up the good point that develoepers should be
> building and testing with what we release.

The drawback I see with this approach is that a large number of source
files need to be modified and recompiled when building the jars. With
David's original approach, only the shared files need to be modified
right before compilation, whereas with Kathey's approach, the shared
source files as well as the dependent source files need to be modified
before compilation for inclusion in the jars. This introduces a
dependency on having a clean environment before a 'production' build,
since for a production build, you need all the shared and dependant
files modified before a build - which is potentially a large number of
source files. In contrast, with David's approach, alterations to
dependent files are zero, and you only need to generate the new shared
files right before compilation. Since it seems that the number of
shared source files will be significantly less than the number of
dependent source files, I'm leaning towards David's approach at the
moment.

Part of the problem depends on how much time developers are willing to
wait for a jar build. The time necessary to clobber, then copy, alter,
recompile the new source, and then package a 'production' build -  the
build that you are supposed to run your tests against - may increase
dramatically. In which case, it becomes less attractive to run tests
against a 'production' build for the average developer. And yet
another factor is how well these source modifications work with IDEs
that don't have knowledge of Ant or the source modifications for a
production build.

While we could require developers to conform to a new, different,
lengthy contract for testing with production builds, 'development' and
'production' builds with Kathey's approach would be signficantly less
1-to-1 than they are today, leaving a lot of room for developers to be
lazy with respect to what they are actually testing..

In the past, I've seen serious problems occur because of a disconnect
between development and production builds. So, I think we should
consider introducing any differences between the development and
production testing environments very carefully.

andrew

p.s. I'm a little delirious from illness and antibiotics and lack of
sleep and what-not, but this caught my eye, so I felt the need to
weigh in. I may have a different opinion tomorrow. :-)