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.
Dan.
