Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 16 Jun 2006 13:27:46 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-1032) Create new scripts which follow
 common practice at Apache
In-reply-to: <21310863.1150442550620.JavaMail.jira@brutus>
Sender: David.Vancouvering@Sun.COM
To: derby-dev@db.apache.org
Message-id: <44931442.8040507@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References: <21310863.1150442550620.JavaMail.jira@brutus>
User-Agent: Thunderbird 1.5.0.2 (X11/20060427)

I didn't follow how this solution is going to be backward-compatible. 
I'm assuming we'll be keeping the old ones around, perhaps invoking the 
new ones?

David

Andrew McIntyre (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1032?page=comments#action_12416463 ] 
> 
> Andrew McIntyre commented on DERBY-1032:
> ----------------------------------------
> 
> For this change, I propose the following:
> 
> * create new scripts which replicate the functionality provided by the scripts in the frameworks directories with new scripts which all reside in a single new directory in the -bin distribution: /bin
> 
> * use the environment variable DERBY_HOME to indicate the location of the Derby installation instead of DERBY_INSTALL. A check to verify that the value is valid, for example verifying that DERBY_HOME/lib/derby.jar exists, might be used. However there are some situation where a simple check may not be desired, for example, if NetworkServerControl is being used in an environment without derby.jar. I need to think about this check a little further.
> 
> * use the JAVA_HOME variable to determine the location of the Java installation, instead of relying on the java executable being in the path, and provide appropriate warnings if the variable is not set. If JAVA_HOME is not set or the java executable is not on the path, fail with an error.
> 
> * for maintainability, refactor setup and environment validation to a shared file used by all scripts, although there will be two of these files: one for the set of batch scripts and one for the set of shell scripts.
> 
> * remove the extension for the Unix shell scripts so that the utilities can be executed by their name. e.g. on a Unix system, instead of the current 'ij.ksh', only 'ij' would need to be typed to execute ij if the PATH contains $DERBY_HOME/bin.
> 
> * provide a DERBY_OPTS variable that would allow overriding JVM options and setting Derby JVM properties in the use of the scripts, similar to the ANT_OPTS environment variable. (See DERBY-345)
> 
> The contents of the bin directory would include:
> 
> dblook(.bat)
> derby_common(.sh|.bat)
> ij(.bat)
> NetworkServerControl(.bat)
> setEmbeddedCP(.bat)
> setNetworkClientCP(.bat)
> setNetworkServerCP(.bat)
> startNetworkServer(.bat)
> stopNetworkServer(.bat)
> sysinfo(.bat)
> 
> The (.bat) above indicates that for each Unix shell script without an extension, there will be a corresponding Windows batch file. The script which shares the common setup and environment validation logic, derby_common, will have the .sh extension on Unix to prevent accidental execution in Unix shell environments, even though such execution would be harmless.
> 
> The portability goal for the shell scripts is that they be able to run in any fairly recent shell environment: bash, tcsh, ksh, and zsh on Solaris, Mac OS X, AIX, Linux, and Cygwin and MKS on Windows. Since batch files run only on Windows/DOS, it is only necessary that they meet the requirements listed above.
> 
> Note that my plan is not to remove the scripts in the frameworks directory at this time, since there may be downstream projects that currently use the scripts. However, the scripts in the frameworks directory should be clearly marked as deprecated and that in the future downstream projects should use the scripts in the bin directory instead. It should also be suggested that the utilities can be invoked directly from a command line with 'java -jar' via the new derbyrun.jar.
> 
> Please let me know if you see any problems with this proposal. Otherwise, I will post a patch shortly that contains the new scripts for the top-level bin directory.
> 
>> Create new scripts which follow common practice at Apache
>> ---------------------------------------------------------
>>
>>          Key: DERBY-1032
>>          URL: http://issues.apache.org/jira/browse/DERBY-1032
>>      Project: Derby
>>         Type: Improvement
> 
>>   Components: Demos/Scripts
>>     Versions: 10.2.0.0
>>     Reporter: Andrew McIntyre
>>     Assignee: Andrew McIntyre
>>     Priority: Minor
> 
>> Scripts for Derby should be written to follow common practice at Apache. This means locating them in a bin directory, and self configuring from the minimum amount of information necessary: installation location and in our case, the location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. If these variables are not set, we should report this to the user. Good examples are available in Ant, Forrest, and Maven, and much of the same setup code can be reused from those projects.
>