Skip to content

File Structure

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

Build classes (called kbeans) can either be defined as source files or provided as binaries by external libs.

Project Structure

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

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

Project Base Directory
+- jekaw
+- jekaw.bat
+- jeka
|  +- local.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 that 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) : Third-party jar files that 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 the Jeka execution engine as compiled classes from def. These files are used as a local cache to speed-up Jeka bootstraping and can be deleted safely.
  • local.properties (file - optional) : Contains properties defined at project level, such as java version.

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 must be launched from the root of the project (and not from [Project Root]/jeka).

Note

When generating a project using a scaffold mechanism, these files are created with explanations in their bodies.

Jeka Wrapper

Jeka wrapper consists of shell scripts, a thin booting jar, and a configuration file in order for Jeka to 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 use Unix like and Windows scripts respectively, to launch the 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 be used.

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 :

  • global.properties (file - optional) : Properties defined at the global level (see later section).
  • cache (directory - generated) : Various files cached by Jeka as downloaded files, 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 there are downloaded dependency artifacts.