This article provides tips and workarounds when using the command-line interface.
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.
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.
JAVA_HOME
variable is used to find the Java command, then the JAVA_HOME
/bin
directory is added to the local path on Windows™.
zero version
command displays the location of the Java command that is being used. The scripts
also support a debug mode that displays additional information. Edit the zero script to enable debug, which also displays the Java command that is used.
The command-line scripts require several commands on Linux™ and Mac. The list includes:
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.
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.