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
