db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: derbytools.jar loading derbyclient.jar
Date Wed, 01 Mar 2006 22:21:55 GMT
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


Mime
View raw message