If a Java application (not J2EE app) provides a database creation utility and expects to be able to use a JDBC network driver to connect to the Derby network server embedded in Geronimo, then currently the command line application (the database creation utility) needs access (assuming the IBM Universal Driver is used) to db2jcc.jar and db2jcc_license_c.jar .
On the Derby lists I saw that IBM is planning on donating a JDBC network driver sometime in March.
Q1. Would it make sense to place this driver jar and the derbytools jar in the geronimo/repository/incubator-derby/jars directory to accompany the other derby jars so we provide all the required jars needed for connecting to and administering the Derby database embedded in Geronimo (even though the driver or tools won't be loaded by Geronimo)?
Yes - we already configure and start the network server so having the client jars available would make sense. These could also be used to connect to a Derby instance in a different JVM.
Q2. Even if we do provide all the JARs in the repository, users of a command line Java application (running on the same machine) would probably have to edit their classpath to point to the correct version of JDBC driver that matches the version of Derby embedded in Geronimo. Any suggestions on how this could be automated (determining the version and getting the driver JAR)?
I think it would depend on how the client app expected this to work and whether it relied on having them in the system classpath or did some fancy uber-jar type thing.
One option would be to deploy the client along with the server (EAR) as a J2EE Application Client. IIRC the app client can have a plan associated with it where they can specify dependencies just like with server-side modules.
-- Jeremy
