The distribution comes in the form of a gzip-ed tar archive, e.g. ScriptRunner-M.N.tar.gz or ScriptRunner-M.N-src.tar.gz. Execute the command:
tar xvfz ScriptRunner-M.N.tar.gz
(or gunzip followed by tar xvf). This will extract the files into a directory ScriptRunner-M.N/. All command line scripts should now be available, e.g. try:
ScriptRunner-M.N/bin/sr -h
The simplest choice is to use flat files. When executing ScriptRunner, simply set the property sruns to point to an appropriate directory. E.g.:
sr -Dsruns=${HOME}/ProjectX X.xml
A new sub-directory sruns will be created in the directory (in the example, ${HOME}/ProjectX/sruns/). For each run, files storing the persisted audit trail data will be created in that sub-directory.
Note that if the property sruns is not set, the current working directory is assumed.
More powerful than flat files is a database. To use a database-backed ExecutionContext, there are some database objects to install: a few tables (for logging, restart and benchmarking); a couple of sequences (for the run identifier and run log); a view to help monitor run progress; and a number of functions or procedures. Exactly how these are packaged depends on the DBMS.
Go to the ScriptRunner-M.N/sql/Oracle/ directory; and choose a database user to run sr_install.sql. This creates the database objects mentioned, a package sr for most of the functions and procedures and a public synonym for the package. Public is granted all on the package. A test user is also created.
To uninstall, run sr_uninstall.sql.
A schema sr is created to segregate all the database objects. To install, go to the ScriptRunner-M.N/sql/Postgres/ directory; and choose a database user to run sr_install.sql. A role srRole is created which can be granted to users of the schema. See for instance sr_user.sql.
To uninstall, run sr_uninstall.sql.