This topic contains a list of the module commands available from the command line
The command compiles all Java source files (*.java) under the module's /java directory and puts the resulting class files (*.class) under /classes. It 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. Individual arguments can be specified with -arg, for example, zero compile -arg=-Xlint:unchecked. The second way is to place the java compile args in a file and use -@ to specify the file.
The command creates a new module under the current working directory. In the first and simplest use of the command, the default module template is used to fill in the module directory, and then the module is resolved.
The module name can not start with a space and is limited to the following characters: a-z,A-Z 0-9,_ and " " ( space).
The second and third uses of the command allow you to create an module from existing modules. If you linkto another module, the command will set that module as the only dependency. If you create an module from another module, the command will make a local copy of the module and make the appropriate name fixes.
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>.
Package 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 a shared package is created. A shared package resolves all its dependencies to the local repository. A standalone package contains a private repository with all the required modules. 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.
An easier way to share modules is create the modules as peers. The local resolver will find peer modules before looking in the local and/or remote repositories.
The standalone package includes everything to be able to resolve and start the package except a jvm. The command line scripts and bootstrapping features are included, so the package can be unzipped and then resolved and started. The command line does not need to be separately installed.
The includeSrc option adds the Java directory to your package.
The command maintains an exclude list to exclude unnecessary files like version 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 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 -overwrite.
The resolve command uses the module's config/ivy.xml file to build up the module's dependencies. 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, including transitives, and the location of the dependencies. The list of dependencies is used when determining the virtual directories of the module. The resolve will first try to find modules as peer projects, then within the local repository and then within the configured remote repositories.
The resolve also creates a .zero/shared/resolve.history file that is used to lock the resolve command to the current versions. A subsequent resolve will use the history to filter out non matching versions. See the update command for a resolve that ignores the history and will resolve against the latest matching modules. If a resolve or update command detects a change then a new history is created with the previous history moved under the .zero/private directory. The resolve command is typically locked after the first resolve and will not generate new history files unless a module dependency is added or removed. The history file allows a resolve/update to be reverted using the rollback command
The command reverts the effects of the last resolve or update command. The command uses the history file to determine the previous versions of all modules and performs an update using those versions. Note that the command can only revert one update.
The command uses the current module group to find in the local repository for a module that matches the given <org:module:version> 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 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 command allows resolving the module ignoring the previous resolve history. The resolve command is locked into a version in local repository if it has a history file. The update command should be used when you want to resolve against all versions available in the local repository.
The -report option will display what versions would be used, but doesn't actually make the change. This allows you to see what updates are available without any modifications.
The command displays the following information