Daniel John Debrunner wrote:
Bryan Pendleton wrote:
Here's a thought for a totally different approach to solving
the original problem, which I will unfairly summarize as:
Make it easier for brand new users to run Derby in trial
situations without having to learn a lot about scripts and
CLASSPATH settings.
What if we shipped two configurations of the Derby classes:
- the first configuration is the current one, with the Derby
classes broken out into the separate jars. Each jar
continues to be independent (no Class-Path manifest entries)
- the new configuration is a single jar ("derbyall.jar", say)
which has all the classes from derby.jar, derbytools.jar,
derbynet.jar and derbyclient.jar in a single jar file.
Then, the "new user" tools and examples could just tell users
to run things like
java -jar derbyall.jar ij
java -jar derbyall.jar NetworkServerControl start
While the more advanced user, who wants to carefully load only
the necessary classes, mix-and-match versions, etc., could
continue to use the separate jar files as they did before.
What do you think? Does an approach like this offer any value?
That's a great idea, I would add one minor modification.
Don't have the classes in derbyall.jar, just Class-path entries.
Class-Path: derbynet.jar derbytools.jar derbyclient.jar
Then it's (almost) the same functionality for almost zero overhead.
The name may want to change as well, something that indicates it's
really only for use as a command line tool. derbycmd.jar doesn't quite
seem right, maybe others have better ideas.
Dan.
It just keeps getting better. + 1
