Skip to content

File Structure

The execution engine let to execute an arbitrary Java/Kotlin method from the command line or from an IDE. Methods are declared in regular Java/Kotlin classes.

Build classes can be defined either as source or .class files into the project to build.

Project Structure

Every Jeka execution takes place in the context of a project. A Jeka project is a folder strucure containing a 'jeka' directory at its root. Execution must be launched from project root directory.

All of the following files or directories are optional except the jeka directory.

Project Base Directory
+- jekaw
+- jekaw.bat
+- jeka
|  +- cmd.properties
|  +- project.properties
|  +- boot
|  |  +- somelibs.jar
|  +- def
|  |  +- SomeBuild.java
|  |  +- SomeUtils.java
|  |  +- ...
|  +- wrapper
|  |  +- dev.jeka.core-wrapper.jar
|  |  +- wrapper.properties
|  +- output
|  |  +- ...        
|  +- .work
|  |  +- ...
+- ... (project specific files like src/main/java, src/test/java, ...)

Jeka Directory Content

By convention, every project automated or built by Jeka contains a jeka directory at its root ([Project Root]/jeka). This directory contains everything Jeka needs to automate or build the project.

In this directory, you may find :

  • def (directory - optional) : User Java and/or Kotlin sources that will be executed by the execution engine.
  • output (directory - generated) : Files produced by the tasks (jar files, classes, test reports, doc, ...)
  • boot (directory - optional) : 3rd-party jar files users may add to be used by code located in def.
  • wrapper (directory - optional) : Wrapper jar file for bootstrapping a specified version of Jeka.
  • .work (directory - generated): Temp files generated by Jeka execution engine as compiled classes from def.
  • project.properties (file - optional) : Contains properties defined at project level. If the project has a parent directory which holds a jeka/project.properties file, then those values are inherited by the child project.
  • cmd.properties (file - optional) : Contains predefined command shortcuts that can be invoked with a single keyword.

Project root may also contain jekaw and jekaw.bat shell scripts to invoke Jeka wrapper conveniently.

For the following, when we refer to the command jeka, you can use ./jekaw indifferently. All command lines are supposed to be launched from the root of the project (and not from [Project Root]/jeka).

Note

When generating a project by scaffold mechanism, these files are created along self explanation inside their body.

Jeka Wrapper

Jeka wrapper consists in shell scripts, a thin booting jar and a configuration file in order Jeka can be executed on a specified version without being installed on the host machine. This is the recommended way of using Jeka as it makes builds portable from one machine to another.

  • jekaw and jekaw.bat are respectively Unix like and Windows scripts to launch bootstrapping jar.
  • jeka/wrapper/dev.jeka.core-wrapper.jar is the bootable jar in charge of downloading and installing the specified Jeka version on the host machine prior to launch Jeka
  • jeka/wrapper/wrapper.properties specifies the Jeka version to use.

When Jeka wrapper is installed on a project, execute jekaw instead of jeka.

Jeka User Directory

Jeka automatically creates a directory [User Home]/.jeka when running for the first time. This directory may contain :

  • options.properties (file - optional) : Properties defined at global level (see later section).
  • cache (directory - generated) : Various files cached by Jeka as downloaded files and specifically dependency artifacts. This directory can be safely deleted.
  • maven_publish_dir (directory - generated) : Contains artifacts that your projects have published locally respecting Maven repository standards
  • ivy_publish_dir (directory - generated) : Contains artifacts that your projects have published locally respecting Ivy repository standards

In the contrary of Maven, Jeka does not publish locally on the same repository where are downloaded dependency artifacts.