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 (hermes.apache.org: local policy)
Message-ID: <4272777B.7000406@apache.org>
Date: Fri, 29 Apr 2005 11:05:47 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Use of 3rd party libraries
References: <4271BDBA.6050700@apache.org> <427239AD.6080402@bellsouth.net>
 <4272635B.409@debrunners.com>
In-Reply-To: <4272635B.409@debrunners.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:
> Edward Rayl wrote:
> 
> 
>>I think any proposed changes should be invisible to the developer using
>>Derby.  Therefore I think alternatives A or D make the most sense.  I
>>would only choose D if the perceived benefit justifies it.
> 
> 
>>a) stick with what is done now and use our own versions
>>d) have the build include the library content in derby.jar 
> 
> 
> 
> +1
> 
> I downloaded another open source project a while ago, and then found I
> needed to download five additional open source ("third-party") libraries
>  before I could use the project. I carefully did this, following the
> original project's instructions of getting a specific version or some
> version or later. The with a correct class path I immediately hit an
> abstract method error, indicating there was some mismatch in these six
> libraries. I gave up at that point. I would hate to see that kind of
> situation for Derby, really takes away from the ease of use for everyone.
> 

The simple solution to that is to include the dependent jars with the 
distribution rather than make the user download them. Alternatively, 
careful version definition (as done by maven) can support 
download-on-demand without that kind of problem.

--
Jeremy