db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Thu, 15 Sep 2005 21:45:09 GMT
David W. Van Couvering wrote:

> On thinking further about this, I have a couple more questions/concerns
> 
> - I think Jeremy has a very good point that has not been directly
> answered.  If we do not allow potential compatibility issues by running
> multiple versions in the same VM, then doesn't that mean we are not
> going to be willing to incorporate third-party components like from
> Jakarta Commons?

No. If we have common code, I don't see how it matters if it's written
as part of Derby or elsewhere. We would take the same approach for both.

> I think this is a real problem, and I think a stance like this would not
> be looked upon positively from the rest of the Apache community.

No-one has suggested such a stance.

But as an aside, I once downloaded an open source project, which then
instructed me to fetch a further five or six common Apache libraries,
either at a specific version numbers or higher than a given version. I
followed all this correctly, set up the classpath and immediately got an
abstract method error.

That's an example of badly managed common versions, and I do not wish
Derby to fall into the same trap.

1) The ease to download goes away in that case where I had to spend time
finding and downloading N additional jars.

2) The ease to use goes away when I have to modify the classpath to add
six or seven jars.

3) The desire to use goes away completely when having followed the
instructions the product fails.

This e-mail isn't to solict ideas on how specifics can be solved, but to
 understand that Derby's ease of use in all aspects is one of its
greatest strengths, we cannot forget that, or lose it.

Dan.



Mime
View raw message