This topic describes the commands that are always available through the command-line interface to all modules.
The Overview provides general command-line information.
These commands support the lifecycle of maintaining a module.
Compiles all Java source files under the module's /java directory.
The command compiles all Java source files (*.java) under the module's java directory, the resulting class files (*.class) are generated under the classes directory. The command does not compile or re-compile any source files that are part of the module's dependencies. Java compile arguments can be passed in one of two ways, directly or wrappered with the -arg and -@ option.
Any argument that the command does not recognize will be passed to the underlying compile command, for example
zero compile -Xlint:unchecked
. To determine the supported arguments just type
zero compile -help
.
The wrappered approach uses the -arg or -@ options, and is consistent with other commands. Individual compile
arguments can be specified with -arg, for example, zero compile -arg=-Xlint:unchecked
. The -@
option can be used to pass a file that contains the compile options.
The compile command by default will use the javac found using the environment variable java.home. The -ecj option allows using the eclipse compiler for java instead by specifying the path to the ecj jar.
The return codes for this command are:
Creates a new module in the current directory.
The command creates a new module under the current working directory. The create command has three usages;
create a new module, create a module linked to an existing module and create a copy of an existing module.
The first create will create a new module from the template zero.application.template
. The
linkto create also creates a module using the template zero.application.template
but the
module dependencies are modified to the linkto module. The from create will make a copy of the existing
module and then modify the module name to be the specified name.
The module name cannot start with a space and is limited to the following characters: a-z,A-Z,0-9,_ and " " ( space).
The create will update the new module, the following options are passed to the update command.
The -ignorepeers will perform the resolve without any peer modules.
The -dir option allows specifying the parent root directory for modules that can be included in the resolve.
The -module option allows specifying individual modules that can be included in the resolve.
The return codes for this command are:
Prints the documentation for the given command.
If there no command specified, then the short help for all available commands is displayed. For help on a specific command, type zero help <command>.
Packages the module as a zip file.
The command packages the module into a zip file for sharing and/or redistribution. There are two types of packaging, shared and standalone. If the type is not specified then the shared package is created.
The shared package is a smaller package that does not include any of module's dependencies. The shared package it typically published into the local repository, but can also be moved to another machine. If the shared package is moved to another machine then it will need to be resolved, so all the modules dependencies need to be available through other shared packages or remote repositories.
An easier way to share modules is to create the modules as peers. The local resolver will find peer modules before looking in the local and/or remote repositories.
The standalone package is a much larger package that contains a private repository with all the required modules. The standalone package also includes a copy of the CLI, so the zip can be expanded resolved and started on another machine, the only requirement is a JDK.
The package command will fail if the package already exists, to force creating the package use the -overwrite option. This command can be combined with the publish command, if the package is to be shared via a repository.
The -includeSrc option adds the Java directory to your package.
The command maintains an exclude list to exclude unnecessary files like revision control files and the .zero/private directory. You can exclude additional files from the package by using the -excludes option. The excludes pattern is a regular expression pattern. For example, if the package should not include the files in the public folder the following excludes pattern could be used.
zero package -excludes=".*/public/.*"
The -overwrite option will allow overwriting an existing package.
The -export option allows specifying the directory where the package will be created, the default location is the export directory of the module.
The return codes for this command are:
Publish the module to your local repository.
The command publishes the zip created by the package command to the local repository.
The zip is typically located in the module's export directory but the file can be specified with the -f option.
The publish can fail if the module is already in the repository but the publish can be forced with the -overwrite option.
The return codes for this command are:
Determine the module's dependencies.
The resolve command is used to determine the dependencies for a module, including any transitive dependencies, and verifying that all the dependencies are available. The module's dependencies are determined based on the module's config/ivy.xml file.
The results of the resolve can be found in .zero/private/resolved.properties file. The information includes a fully qualified classpath, a list of all dependencies, and the location of the dependencies. The list of dependencies is for the virtual directories feature of WebSphere sMash.
The resolve will first look for modules in the private repository, workspace modules, local repository modules and if a match is not found then uses the configured remote repositories. The modules that are found with the workspace resolver can be configure through the -dir and -module option. The directory specified with -dir is used to list all modules in that directory. The -module option is used to specify a single module. The default for workspace modules is to find modules using the parent directory of the current module. The workspace resolver can be disabled with the -ignorepeers option.
The resolve creates a .zero/shared/resolve.history file that is used to lock resolve to use the same module revisions for future resolves. The subsequent resolve will use the history file to filter out non matching revisions of modules. An application can be updated to the latest revisions in the local repository by using the zero update command. The difference between the resolve and the update is the update does not lock the modules to the revisions stored in the history file. If an update causes undesired changes to the application, then the resolve can be undone using the rollback command.
The -ivy option allows specifying the ivy file to use, the default is to use the ivy.ixm in the config directory.
The -resolver allows specifying the resolver to use, the default is localThenRemote.
The -report option will report the results of the resolve without actually performing the resolve.
The -ignorepeers will perform the resolve without any peer modules.
The -dir option allows specifying the parent root directory for modules that can be included in the resolve.
The -module option allows specifying individual modules that can be included in the resolve.
The return codes for this command are:
Reverts the effects of the last resolve or update.
The command reverts the effects of the last resolve or update command. The command uses the history file to determine the previous revision of all modules and performs an update using those revisions. Note that the command can only rollback one update.
The return codes for this command are:
Finds and prints all matching modules in the repository.
The command uses the current module group to find in the local repository for a module that matches the given <org:module:revision> value and prints its search results. If no module name is given, the command will print information about all available modules. You can also use the -remote option to tell the command to search the remote repository instead of the local one.
If the -json option is used the report is formatted as a JSON document.
The return codes for this command are:
Switch the module group.
The switch command allows changing the module group for a module or the CLI. The command will change the module group, if the module has already been configured and then performs an update. See the 'modulegroup create' command for creating modulegroups.
The create command uses the module group from the CLI. If you want to create modules for another module group, then switch the CLI by executing the command in zerohome. Otherwise, the switch command can be issued on an individual module by executing switch under module's directory. The version command can be used to determine the CLI and/or module's module group.
The -ignorepeers will perform the resolve without any peer modules.
The -dir option allows specifying the parent root directory for modules that can be included in the resolve.
The -module option allows specifying individual modules that can be included in the resolve.
The return codes for this command are:
Resolves a module to its latest dependencies.
The command allows resolving the module ignoring the previous resolve history. The resolve command is locked into a revision in local repository if it has a history file. The update command should be used when you want to resolve against all revisions available in the local repository.
The -ivy option allows specifying the ivy file to use, the default is to use the ivy.ixm in the config directory.
The -resolver allows specifying the resolver to use, the default is localThenRemote.
The -report option will display what revisions would be used, but doesn't actually make the change. This allows you to see what updates are available without any modifications.
The -ignorepeers will perform the resolve without any peer modules.
The -dir option allows specifying the parent root directory for modules that can be included in the resolve.
The -module option allows specifying individual modules that can be included in the resolve.
The return codes for this command are:
Displays version information
The command displays the following information
The return codes for this command are:
These commands support the lifecycle of maintaining a module group.
Adds a remote repository to the module group.
The command will add a repository to the set of remote repositories contained in the module group resolver chain.
The <host> is the url to remote repository. There are currently two types of supported repositories, WebSphere sMash repositories and maven repositories. The type of repository can be indicated with zero= or maven=, respectively. A WebSphere sMash repository is assumed if the type is not specified with the url, but can be explicitly set with zero=host_url. An example of a WebSphere sMash repository is zero=https://www.projectzero.org/repo/zero.repo.latest. The second type of repository is a maven repository, which is indicated by maven=. An example maven repository is maven=http://repo1.maven.org/maven2/.
The -validate option will verify the host exists by trying to connect to it.
The return codes for this command are:
Creates a new module group in the local repository.
The command creates a new module group with the given name in the local repository. If the name is not one of the known module groups contained in config/bootstrap.properties, then the host parameter(s) are required parameters.
The bootstrap.properties file contains the default module group and the host url(s) for the repositories that define that module group. This file allows default behavior for the bootstrap experience. But this file is only referenced the first time a module group is created. See the modulegroup addurl information to add a repository to an existing module group.
This command allows creating a new modulegroup that resolves against the specified repository. Additional hosts can be specified, but the first host must point to a WebSphere sMash repository that contains zero.kernel and zero.cli.tasks.
The <host> is the url to remote repository. There are currently two types of supported repositories, WebSphere sMash repositories and maven repositories. The type of repository can be indicated with zero= or maven=, respectively. A WebSphere sMash repository is assumed if the type is not specified with the url, but can be explicitly set with zero=host_url. An example of a WebSphere sMash repository is zero=https://www.projectzero.org/repo/zero.repo.latest. The second type of repository is a maven repository, which is indicated by maven=. An example maven repository is maven=http://repo1.maven.org/maven2/.
The return codes for this command are:
Deletes a module from the local repository.
The command allows you to delete a specific revision of a module from your local repository. For example, you may delete zero.core revision 1.0 (zero:zero.core:1.0). The command requires at least 1 module to delete and can take up to N arguments. The command will fail if the module is a resolved dependency of the command-line, or the current module. See zero version to determine the resolved modules.
The -report option allows the operation to perform but no changes are made. The list of changes is sent to the console.
The return codes for this command are:
Removes a given module group from the local repository.
The command removes an existing module group from the local repository. The command will fail if the module group is the module group used by the command-line, or the current module. See zero version to determine the module group being used.
The return codes for this command are:
Get the specified modules
The command gets a given module by copying the requested revision from the remote repository. A module specification is required, to get all modules the use all.
The -n option controls the number of revisions to retrieve, the default is 1.
The -report performs the operation but does not make any of the changes. The list of changes is sent to the console.
If the -json option is used the report is formatted as a JSON document.
The return codes for this command are:
Prints the documentation for the given subcommand.
The command prints the documentation for the given subcommand. If no command is provided, it will print a short summary of all subcommands.
Prints the contents of the site.xml.
The command will print the contents of the site.xml. If the -json option is used, the report is formatted as a JSON document.
The return codes for this command are:
Finds and prints all modules.
The command prints information about all available modules. If the -json option is used the report is formatted as a JSON document.
The -validate option will verify the modules in the module group by checking against the checksums. Any modules that fail the checksum test will be reported and should be deleted from the module group.
The return codes for this command are:
Removes unused versions of modules from a repository.
The command removes older revisions of modules but at least N, specified with -n, revisions are kept. If no module is specified, the operation is performed against all modules. The -n option controls the latest number of revisions to keep, the default is 1. The command will fail if the module is a resolved dependency of the command-line, or the current module. See zero version to determine the resolved modules.
The -report option performs the operation but makes no changes. A list of the potential deletions is sent to the console.
The return codes for this command are:
Update the modules to the latest versions.
The command can be used to update the modules that currently reside in the local repository with newer revisions from a remote repository. Once the local repository has been updated, individual modules can be updated to newer revisions by using zero update.
If an argument is specified on the command, then a single module is updated. This case is is equivalent to the modulegroup get command and it is encouraged to use modulegroup get instead.
The -n option controls the number of revisions to retrieve, the default is 1.
The -report performs the operation but does not make any of the changes. The list of changes is sent to the console.
If the -json option is used the report is formatted as a JSON document.
The return codes for this command are:
These commands support the lifecycle of maintaining a repository.
Prints the documentation for the given subcommand.
For help on a specific subcommand, type zero repository help <subcommand>.
Prints basic configuration data all repositories (module groups).
The command prints basic configuration data about all of the available repositories.
If the -json option is used the report is formatted as a JSON document.
The return codes for this command are:
Lists the modules contained in specified modulegroup.
The command lists the modules contained in the specifed module group. The modulegroup can be one of the configured modulegroups or the path to a private shared repository on the file system.
If the -json option is used the report is formatted as a JSON document.
The return codes for this command are:
Publish the module to the specified modulegroup.
The command publishes the zip created by the package command to the specified modulegroup. The zip is typically located in the module's export directory. The modulegroup can be one of the configured modulegroups or the path to a private shared repository.
The zip is typically located in the module's export directory but the file can be specified with the -f option.
The -overwrite option forces the publish command to succeed when the module already exists in the repository.
The return codes for this command are: