Command line interface tasks

The zero.cli.tasks extension provides the base tasks available through the command line interface (CLI). The CLI tasks are split up the following categories: module tasks, module group tasks, and repository tasks.

The commands are described in the respective sections according to these groupings. This set defines the minimum set of commands available to a module. The commands are CLITask handlers that registered through the virtual browsing feature of all modules. So additional commands can be introduced to a module by adding dependencies that provide CLITasks. The easiest way to see what tasks are available is to use zero help.

The zero.cli.tasks module provides the following tasks:

Each individual command documents the supported options, but there are some common options for all commands. The logging feature is implemented using these common options for the command line. The default logging is console-only for all tasks except run. The logging.properties file will be inherited from the zero.kernel module, unless the module provides one. The logging feature provides the -logfile and -loglevel options. The -logfile=file option redirects the logging output to the specified file. The -loglevel=level option will control the logging level. The levels are the java.util.logging.levels including SEVERE, WARNING, INFO, FINE, FINER, and FINEST.

The module group tasks allow creating a repository of modules that can be used to resolve against. The default module group for IBM® WebSphere® sMash is the stable module group, which retrieves released modules from the WebSphere sMash repository. The known module groups and the default module group is defined in the config/bootstrap.properties. The typical usage would be to just start using the CLI with the stable module group. Other module groups can also be created with the zero modulegroup create command.

The default module group must either be a known module group or configured through zero modulegroup create. The known module groups are the stable module group, which retrieves officially released modules from the WebSphere sMash repository and the experimental module group, which retrieves the latest modules from the WebSphere sMash repository.

ProductKnown module groups
WebSphere sMashstable
WebSphere sMash DEexperimental, stable(default)
Project Zeroexperimental

The location of the root of the zero repositories is configured in the config/local.properties file. The default location is repo.root=${zerohome}/zero-repository. Some installations might not have write access to the location where the CLI is installed, so another popular option for the repo.root is ${user.home}/zero-repository. A fully qualified path can also be specified.

DBCS characters are not supported for the repo.root at this time.

The local.properties file also allows configuring the timeout for the ivy resolves. There are two configurable timeouts, the units for both are in seconds. Connect timeout is the amount of time for establishing a connection with the host. The read timeout is the amount of time to start to read from the input stream for the connection. A value of 0 is an infinite timeout.

# connect timeout is in seconds, default is 1 minutes 
http.connect.timeout=60
# read timeout is in seconds, default is 30 seconds 
http.read.timeout=30

Exit codes on windows

The command line scripts on windows exit with exit /b exit_code so the current command prompt is not closed. However, if the script is invoked programmatically with cmd /c for example, then the exit code is always success, 0. The environment property ZERO_EXIT_CMD was introduced so that the script can exit with exit exit_code and the correct exit code value can be retrieved. The environment property ZERO_EXIT_CMD should be set to "true" before invoking the script.

Changing the command line

The command line allows configurations for multiple module groups. The configured module groups for the command line can affect existing applications when changing the command line. Consider the situation where the sMash command line is used and the application was created using the stable module group. If you decide to change to the lastest command line from Project Zero, then only the experimental module group is available by default. A resolve of the stable application will fail with a message that the module group stable is not a configured module group. There are two options to fix up the existing stable application. The first is to use the zero switch command to switch the application to the experimental module group.

A second choice is create the stable module group for the new command line interface using zero modulegroup create stable <stable_url>. The stable_url needs to be supplied because it is not preconfigured in the config/bootstrap.properties file for the command line from Project Zero. The supplied url can be the same one used by the experimental module group, or the urls from the existing stable command line can be supplied.

Command line arguments

Certain arguments for the command line need to be quoted so they are not automatically expanded or parsed incorrectly. The first case is spaces in the argument. If for example, you want to create a module at c:/my path/test, the argument c:/my path/test must be quoted because of the space in the path. The command in this case would be:

zero create "c:/my path/test" 	

The second argument that needs to be quoted is the star, *. If the * is not quoted then it is replaced with the names of all the files in the current directory. An example of when the * needs to be quoted is with the command zero modulegroup get. One way to get all the modules from a zero repository is to use zero modulegroup get with the argument *. To prevent the * from getting expanded quotes must be used on both windows and linux platforms. For example, one of the commands to get all modules is

zero modulegroup get "*" 	

The command zero modulegroup get also supports the argument all to get all modules.