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?
+1
I like it!
