Daniel John Debrunner wrote:
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.
And how many open source projects have you downloaded or used without
such issues? Please don't taint this from one bad experience.
For build-time dependencies, many of these issues are addressed by Maven
which automatically downloads the dependencies specified in the project.
This would be an immediate solution to the problem raised on the
recent junit thread.
For run-time dependencies, these can be addressed with solutions like
uberjar:
1) for Derby as a standalone server, we can have one executable jar that
loads all dependencies from an internal classloader (no classpath
issues at all)
2) for Derby as a library, the application embedding us should be using
the same type of solution and we would fit in there just like
clogging. With it controlling the classpath there is nothing for the
user to (mis-)configure
All of these lead to a simple end-user experience - whether they are
trying to build from source, use a standalone server, or embed inside
another application.
--
Jeremy
