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.
Ed
I would like to raise the issue of using 3rd party libraries with Derby.
For example, in another thread we are talking about command line
interfaces. Traditionally Derby has implemented all its own parsing
for this included in the main or tool jar. A lot of other Apache
projects use commons-cli which is a small (<32k) library that
implements this functionality; using this would save coding but create
an external dependency.
I would be interested in the community's view on using this type of
library code. Should we:
a) stick with what is done now and use our own versions
b) use external libraries and require the user to make sure they are
available (e.g. are on the classpath)
c) use external libraries and a manifest class-path entry to ensure
they are included
d) have the build include the library content in derby.jar
e) some other alternative
--
Jeremy
