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: neutral (asf.osuosl.org: local policy)
Message-ID: <4321D9EE.9070908@apache.org>
Date: Fri, 09 Sep 2005 11:52:30 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: VOTE: Approach for sharing code
References: <431F8896.605@sun.com>
 <43207ABC.8080000@sbcglobal.net>	 <43208918.8050706@debrunners.com>
 <4321049C.2080701@sun.com>	 <4321B390.3040401@sbcglobal.net>
 <4321BDD4.4030409@debrunners.com> <54ac72d7050909110277aada6a@mail.gmail.com>
 <4321D820.1010008@debrunners.com>
In-Reply-To: <4321D820.1010008@debrunners.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:
> Andrew McIntyre wrote:
>>>
>>>I would be very tempted to veto any approach that had the jars
>>>containing different code to that built in the classes directory and
>>>usually(?) used for testing by developers. I believe it increases the
>>>chance for problems being introduced in this process but not caught.
>>
>>
>>Does this mean you would object to both of Kathey's proposed options?
>>Obfuscator-type modification of the binaries, or ant-based
>>preprocessing of the source? It wasn't totally clear from this mail if
>>that was the case.
> 
> 
> Both, any solution where the content of the jar files does not match the
> content of a non-jar build.
> 

I'm with Dan on this - one of the advantages we have is openness and 
post-compilation modification of the binary is quite the opposite.

--
Jeremy