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.
