Skip to content


Def classes

Java or Kotlin source files present in jeka/def dir. They can be declared at root or in packages. Execution engine compiles these files on the fly prior adding them to the Jeka classpath.

It is possible to specify compilation options by annotating a def class as :

@JkCompileOption({"-processorPath", "/foo/bar"})
class MyBuild {


  • jeka/def can also contain classpath resources.
  • Classes having a name starting by _ are skipped from compilation.

Java source files are compiled using the running JDK.

Kotlin sources are compiled using Kotlin version specified by jeka.kotlin.version property if present or using Kotlin compiler specified by KOTLIN_HOME environment variable.

Jeka Classpath

Under the hood, Jeka simply executes Java byte code within a flat classloader. Classloader's classpath is constructed from :

  • jar files present in jeka/boot dir
  • dependencies injected via command line and annotation
  • compiled def classes
  • Jeka classpaths coming from imported projects.

Injected Dependencies

It's possible to inject transitively dependencies into classpath by either annotating def classes or by mentionning it in command line.


By default, jeka fetch dependencies from maven central (

You can select another default repository by setting the options. We recommend storing this value in your [USER DIR]/.jeka/ file to be reused across projects.

For more details, see JkRepoFromOptions javadoc.

Inject from Def Classes

Annotate a def class with @JkInjectClasspath mentioning either a module coordinate or a path on the local file system.

class MyBuild {


Update your IDE dependencies right after adding this annotation in order it can be used inside your def classes. jeka intellij#iml or jeka eclipse#files


Dependencies imported via @JkInjectClasspath are imported for all def classes and not only for annotated class.

Inject from Command Line

Specify path or module coordinates in the command line using '@' as or @../libs/myutils.jar.

This feature is meant to invoke KBeans dynamically.

Imported Projects

Jeka supports multi-module projects in Jeka classpath of a given project can include Jeka classpath of another one.

class MyBuild {


KBean is the central concept of execution engine. KBeans are classes where are declared executable methods. There is only one KBean instance by KBean class in a given Jeka project.

KBean classes share the following characteristics :

  • Extend JkBean
  • May declare public void methods taking no arguments. All these methods are invokable from command line.
  • May declare public fields (aka KBean properties). These field values can be injected from command line.
  • They are supposed to be instantiated by the execution engine and not from user code.

Simple Example

The follwing KBeans exposes cleanPublish method which delegate the creation of jar files to the 'project' KBean. ProjectJkBean is available on Jeka classpath as it is part of the standard KBeans bundled in Jeka distribution.

The configure method will be actually invoked at the first ProjectJkBean#getProject() call.

import dev.jeka.core.api.project.JkProject;

@JkDoc("A simple example to illustrate KBean concept.")
public class SimpleJkBean extends JkBean {

    ProjectJkBean projectBean = getBean(ProjectJkBean.class).configure(this::configure);

    @JkDoc("Version of junit-jupiter to use for compiling and running tests")
    public String junitVersion = "5.8.1";

    private void configure(JkProject project) {
                .configureCompileDeps(deps -> deps
                .configureTestDeps(deps -> deps
                        .and("org.junit.jupiter:junit-jupiter:" + junitVersion)

    @JkDoc("Clean, compile, test and create jar files.")
    public void cleanPack() {

    public static void main(String[] args) {
        JkInit.instanceOf(SimpleProjectJkBean.class, args).cleanPublish();


KBean Commands

A KBean command is an instance method of a KBean class that can be invoked from command line. In order to be considered as a command, a method must :

  • be public
  • be an instance method
  • take no argument
  • return void

KBean Properties

A KBean property is a public instance field of a KBean class. Its value can be injected from command line.

Fields can be annotated with @JkInjectProperty("") to inject the value of a property in.

For more details about field accepted types, see dev.jeka.core.tool.FieldInjector#parse method.

KBean properties can also been nested composite objects, see example in ProjectJkBean#pack field.

Naming KBeans

In order to be referenced conveniently, KBeans accept to be called by a name. For a given JkBean class, ccepted names are :

  1. Full qualified class name
  2. Uncapitalized simple class name (e.g. 'myBuild' matches 'org.example.MyBuild')
  3. Uncapitalizes simple class Name without 'JkBean' suffix (.g. 'project' matches 'dev.jeka.core.tool.builtin.project.ProjectJkBean')


Execute jeka, at the root of a project to display KBeans present in Jeka classpath.

Document KBeans

KBean classes, methods and properties can be annotated with @JkDoc annotation in orderder to provide self documentation.

Text within these annotations is displayed when invoking help method on console.

Invoke KBeans

From Command Line

KBean methods can be invoked from command line using

jeka [kbeanName]#methoName [kbeanName]#[propertyName]=xxx

Many methods/properties can be invoked in a single command line.


[kbeanName]# prefix can be omitted. By default, it will be resolved on the first KBean found in def dir. Search is made by fully qualified class name alphabetical order.

From KBean main method

KBean methods can also be launched/debugged from IDE.

In KBean class, declare one or many main methods as :

 public static void main(String[] args) {
        JkInit.instanceOf(MyBuild.class, args).cleanPack();

  public static class Release {
      public static void main(String[] args) {
          JkInit.instanceOf(MyBuild.class, args, "-runIT").release();
KBean must be instantiated using JkInit#instanceOf in order it be setup in proper state.

The arguments passed in main method are interpreted as command line arguments.

Launching or debugging this way is performant as all build classes and their dependencies are already on classpath. Therefore, no compilation or dependency resolution is needed.


Be careful to launch the main method using module dir as working dir. On IntelliJ, this is not the default (it uses project dir).

To change intelliJ defaults, follow : Edit Configurations | Edit configuration templates... | Application | Working Directory : $MODULE_DIR$.

From dev.jeka.core.tool.Main

Sometimes, you may need to mimic closer the command line behavior, for debugging purpose or to pass '@' arguments.

  • Create an IDE launcher for a Java Application
  • Set dev.jeka.tool.Main as Java main class.
  • Set the same command line arguments as you would do for invoking from command line (Do not include jeka command).

Let KBeans cooperate

Generally KBeans interact with each other inside their init method. They access each other using getRuntime().getBean(MyBean.class) as shown in this example.

When a KBean depends on another one, it's good to declare it as an instance property of the first bean as this dependency will be mentioned in the auto-generated documentation.

KBeans in Multi-Projects

In multi-project build, it's quite common that a KBean accesses to a KBean instance coming from another project. You can achieve it in a statically typed way.

  • In master KBean, declare a field of type JkBean (e.g. ´JkBean importedBuild;`). It doesn't have to be public.
  • Annotate it with @JkInjectProject mentioning the relative path of the imported project (e.g. `@JkInjectProject("../anotherModule")).
  • Execute jeka intellij#iml or jeka eclipse#files.
  • Redefine the declared type from JkBean to the concrete type of imported KBean
  • Now, master KBean can access the imported KBean in a static typed way.
  • See example here.
  • Be careful that the imported KBean deals with file paths using JkBean#getBaseDir in order it can be safely executed from any working directory.

Standard KBeans

There is a bunch of KBeans bundle within Jeka. Those KBeans are always present.


ProjectJkBean provides a wrapper around of a JkProject for building JVM-based projects. This KBean initialise a default sensitive project object and provides classic method for building project (compile, package in jar, publish ...)

This KBean proposes extension point through its configure(JkProject) method. This way, other KBeans can modify the properties of the project to build.


IntellijJkBean provides methods for generating metadata files for IntelliJ IDE. Content of iml file is computed according the JkProject object found in project KBean.

This KBean proposes extension point through its configure methods in order to modify the resulting iml (e.g. use a module dependency instead of a library dependency).


ScaffoldjJkBean provides methods for project directories and files to create a new Jeka project. Basically, it creates a project ready to create vanilla automation tasks.

This KBean offers extension point in order other KBean can augment the scaffolded structure. For example, executing jeka scaffold#run will create a basic Jeka project while jeka scaffold#run project# will create a project ready to build a JVM-based project.


GitJkBean exposes some common git command combos.


Properties are pairs of String key-value that are used across Jeka system. It typically carries urls, local paths, tool versions or credentials. They can be globally accessed using JkProperties#get* static method.

Properties can be defined at different level, in order of precedence :

  • System properties : Properties can be defined using system properties as -DpropertyName=value. System properties can be injected from Jeka command line.
  • OS environment variables : Properties can also be defined as OS environment variable.
  • Project : Defined in [Project Root]/jeka/ Used typically for storing tool version (e.g. jeka.kotlin.version=1.5.21).
  • Global : Defined in [User Home]/.jeka/ file. Used typically to define urls, local paths and credentials.

Standard properties :

  • jeka.jdk.X= location of the JDK version X (e.g. jeka.jdk.11=/my/java/jdk11). It is used to compile projects when project JVM target version differs from Jeka running version.
  • : Base url of the repository used to download dependencies
  • jeka.kotlin.version : Version of Kotlin used for compiling both def and Kotlin project sources.