Troubleshooting the command-line

This article provides tips and workarounds when using the command-line interface.

The command-line reports unknown host

The command-line is packaged with only the necessary libraries to support a bootstrap process to download the rest of the required modules. This bootstrap requires that the JDK can access a remote repository using http(s) interfaces. If an unknown host error displays when you are first trying to use the command-line, then there is an issue with accessing the required remote repositories.

The issue is typically due to one of the following problems:

If a proxy is required to access external sites, then the proxy support must be configured through the command-line scripts.

If a proxy is not required, then check to see if there is a firewall blocking the JDKs access external Web sites.

How the CLI determines which Java command to use

The command-line scripts first try to find the Java™ command using the JAVA_HOME environment variable. If the JAVA_HOME variable is set and the JAVA_HOME/bin/java directory exists, then that is the Java command that used. However, if the JAVA_HOME variable is not set, or the JAVA_HOME/bin/java directory does not exist, then the current path environment variable is used to find a Java command.

Shell commands the command-line uses

The command-line scripts require several commands on Linux™ and Mac. The list includes:

The command-line reports task handler was not found

The command-line attempts to find a task handler for the requested command and report an error if a matching handler can not be found. If you get this error, first check that the command name was typed correctly. If you think the command should have been found, like zero start for a module, then make sure the module is resolved. If a module is not resolved, then only the tasks available through module zero.cli.tasks are available. The command zero help can be used to see the list of commands available.

Resolving a standalone package fails

A standalone package includes all of the required dependencies in a private repository, so when it is packaged and moved the resolve should succeed. There was a problem discovered with resolving peer modules with the version checking. The problem occurs when a dependency on a peer module is declared by cutting and pasting one of the existing dependency lines that has the dynamic revision extended to 4 segments, like [1.0.0.0,2.0.0.0[. A new module by default has the revision 1.0.0. The version matchers in ivy by default does not include 1.0.0 in the range [1.0.0.0,2.0.0.0[. This problem has been corrected in sMash by implementing a custom revision strategy, but the problem can still exist for standalone packages using an older CLI.

There are two relatively easy fixes if this problem is encountered with a standalone package. The best solution is to change the dependency line to use the range [1,2[ instead of [1.0.0.0,2.0.0.0[. The revision with 4 segments is a sMash revision strategy that most user developed modules do not require. However, if you prefer to use the sMash style revisions then change the revision for the peer module to be 1.0.0.0, for example. Either of these changes will fix the resolve issue for the standalone packages.