db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Classpaths - WAS Re: [jira] Commented: (DERBY-2366) Tests DerbyNetNewServer and SecureServerTest fails on weme 6.1
Date Fri, 02 Mar 2007 17:51:26 GMT
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.






Mime
View raw message