Myrna van Lunteren (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476220 ]
Myrna van Lunteren commented on DERBY-2366:
-------------------------------------------
Agreed, but unfortunately, derbynet.jar (and derbyclient.jar) is referenced in
derbyrun.jar.
And I think it *is* appropriate to have derbyrun.jar in the classpath.
Or am I wrong in that?
I guess an user can put whatever they want in the classpath. I think
that the documentation should list some typical classpaths, such as:
A) derby.jar - embedded engine
B) derbynet.jar - embedded network server (and standalone)
C) derbyclient.jar - client side application
D) derbyclient.jar + derbytools.jar - client side application with the
tools.
E) derby.jar + derbytools.jar - embedded engine with the tools
The documentation should also indicate for each classpath which other
jars are required and which are optional. E.g. for the classpath of
derbynet.jar the required jar is derby.jar and the optional ones are the
locale jars.
This would then make it easier for users to understand which jars they
need to distribute with their application.
This page kind of supplies the information
http://db.apache.org/derby/docs/dev/getstart/rgslib46043.html
but it might be easier to understand in a "topic" format, where the
topic is the kind of environment the user needs from Derby.
I also think the testing environment should support such classpaths, so
that if anyone has the itch then they can run all the tests with a
specific classpath and not get failures due to a test failing simply
because a jar it requires is not on the classpath. (Hence the
Derby.hasServer() etc. methods).
I'm a great believer in testing how one expects the user to use the
software. Running the tests with all the derby jars in the classpath
does get all the tests to be run easily, but it will miss bugs where
derby.jar incorrectly relies on a class in derbyclient.jar or
derbytools.jar.
Running the tests with just derby.jar in the classpath and removing all
the other jars from the lib folder mimics a true embedded environment
and thus gives one confidence that derby.jar can be used by itself.
Of course such detailed testing is not a requirement but should be an
option for those that want to.
Having said all that, to get back to the question of derby.jar in the
classpath, wrong or right is probably not an issue, but derbyrun.jar is
not intended to set in a classpath. It is intended to be used as a
runnable jar:
jar -jar derbyrun.jar
In this case no classpath is set by the user.
Dan.
