Note: information on this page refers to Ceylon 1.1, not to the current release.


A module is a set of packages together with a module descriptor. A module is packaged as a module archive, which serves as a unit of distribution.


An example module descriptor:

module "1.2.0" {
    import "3.4.1";

This would occur in the source file <source-dir>/com/example/foo/module.ceylon where <source-dir> is a directory containing ceylon source code, conventionally source.


Member packages

The names of the packages in a module must begin with the name of the module, so for example in a module called all package names must begin


The module descriptor holds metadata about the module and is declared in a source file called module.ceylon in the base package of the module (that is the package whose name is the same as the module name). Here's an example:

"An example module."
module "1.2.0" {
    import "3.4.1";
    import org.example.whizzbang "0.5";

The module declaration may be preceeded by annotations, including:

  • doc to let you to specify module-level documentation,
  • license to let you specify the module's license,
  • by to document the module's author or authors.

The module declaration itself starts with the module keyword followed by the module name and version and a list of imports enclosed in braces.

Each dependency of the module must be declared with an import declaration specifying the module name of the dependency and its version.

The import declarations can also be annotated. Annotations particularly worth noting are:

  • shared to mark the imported module as also being exported to clients of this module. If your module uses types from an imported module in its API then the import for that module must be annotated shared in the module descriptor.
  • optional to mark the imported module as being an optional dependency.
  • doc, if there is something about the dependency which is worthy of documentation.


Modules are distributed in .car files, which are essentially .jar files with a different extension, and with a module descriptor.

Modules are kept in a module repository. The list of module repositories to use is passed to ceylon compile, ceylon run, and other tools.

Legacy modules

For interoperability with Java it's possible to convert Java .jar files into Ceylon compatible modules. But for that they need a module descriptor telling Ceylon what it needs to know.

If there is any module descriptor in the jar in the following locations, it will be used:

  • META-INF/jbossmodules/module/name/version/module.xml in the jar, or
  • META-INF/jbossmodules/module/name/version/ in the jar, or
  • META-INF/MANIFEST.MF for OSGi modules in the jar, or
  • META-INF/maven/module/name/pom.xml for Maven modules in the jar.

If there are no module descriptors in the jar, you can provide one externally:

  • Using a file whose format is explained here
  • Or using a JBoss Modules module.xml file whose detailed explanation can be found here

In both cases the file must be placed in the same folder as the .jar file it belongs to. The name of the .jar file itself and the folder structure must adhere to the same rules as those for .car files.

Alternatively, you can use a flat repository to define external module.xml or descriptors in a flat folder.


Modules can be manipulated at runtime via their representation as Module instances. A module's import declarations are represented as Import instances. The modules object can be used to list the modules currently loaded in the virtual machine.

See also