Reference

The earlier chapters built up Jenesis one topic at a time. This one is the flat reference you come back to: how to invoke the build, the target and selector grammar, every jenesis.* configuration key with its default, and the vocabulary of built-in steps a selector can name. Each entry links to the chapter that explains it in full.

Invoking the build

Every project ships its build as source under build/jenesis/Make.java. The canonical invocation recompiles that engine and runs it:

java build/jenesis/Make.java [selectors…]

A package-manager install (see Getting started) adds a second form:

Settings may lead the arguments after the main class (java build/jenesis/Make.java -Djenesis.project.version=1.0.0 build), and @<file> stands for the arguments a file holds - # comments to the end of a line, quotes group, @@<text> is a literal @, and a file names no further file. See Configuration.

Targets

Positional arguments are selectors. With none, the build runs its default target, build, which compiles and packages every module. Project.defaultTarget(...) changes the default (there is no matching property). The top-level targets the shipped layouts register:

Selectors

A selector picks part of the build graph. Three shapes exist.

Module selectors start with +: the active layout rewrites +<name> into that module's path, so one module builds without dragging in its siblings. A nested module is named by joining its path segments with +, as in +api+client. + alone names the module whose descriptor sits at the project root - a root pom.xml that is itself a module; an aggregator-only root or a pure modular project has no such module.

java build/jenesis/Make.java +mymodule      # build just this module's subgraph

Path selectors are a slash-delimited path of module/step identities matched against the graph, with two wildcards:

• : matches exactly one segment.
• :: matches any depth - ::/sign matches every sign step anywhere in the tree.

Wildcards are lenient: a branch that fails to match is silently skipped. A literal path that does not resolve throws Unknown selector: …. Once a step is matched, its predecessors run unconditionally, so its inputs are always real folders.

A +<module> selector narrows build and nothing else. pin, stage and export are entry points of their own, so pin +mymodule runs the whole project's pin and that module's build rather than a pin narrowed to one module. To pin a single module, name its step: the pin target holds one module-<path> step per module, where <path> is the module's source folder URL-encoded, because a selector splits on /.

Configuration keys

Every knob is a system property, passed with -D or set in a jenesis.properties file - see Configuration for files, profiles, and precedence. Some also read an environment variable as a fallback. Defaults apply when the key is unset.

The build prints this same catalogue for itself: configuration lists every key with the value in force and where it came from, one line each, so configuration | grep cache answers what is available and what is set in one step.

Project & layout

The entry point (build/jenesis/Make.java)

Make is the entry point every command names. It carries no build logic and names no engine class, so the Java launcher compiles one small file rather than the whole engine before the build starts. These settings are read from the command line, from your own ~/.jenesis/jenesis.properties and from jenesis.properties at the project root, in that order of precedence.

What a daemon saves is compiling speed, not setup. A Jenesis build has no script to parse - the project is described by pom.xml or module-info.java and configured by properties files - so nothing parsed or compiled is held between calls. What is held is a warm JIT, and a build spends its time inside javac, which a JVM that has already compiled a few modules runs faster. The daemon therefore pays in proportion to how much a build compiles: nothing on a build that compiles little, where the socket costs more than the warm code saves, and about a third off a five-module project. Compiling the build sources once, which is on by default, is what removes the large fixed cost; the daemon is the increment after that.

Only jenesis.* properties travel with a call to a daemon, which clears and sets them again around every build. Everything a running JVM cannot change is the daemon's identity instead - the build sources, the environment, the JVM arguments, any other -D - and a call differing in one of them replaces the daemon rather than being served by one configured for something else.

An ahead-of-time cache answers the same cost without a process. It is a file of the engine's classes, already loaded and linked, which a starting JVM maps instead of loading them again: nothing stays resident between builds, there is no idle timeout, and the cache survives a reboot. The first build with jenesis.make.aot trains it, which takes a build of a few seconds and some 20 MB on disk, and every later build starts from it. It applies where the engine runs compiled, as the installed jenesis command runs it, which is where it saves the most - a no-op build of a one-class project falls from 0.69 to 0.43 seconds. From the classes in .jenesis/classes, a build packs them into a jar and starts a second JVM that can use the cache, which keeps less of the saving. Source mode is out of its reach, because java build/jenesis/Make.java runs in a JVM that started before the cache could be named, so there the setting changes nothing. The jenesis-make tool, which runs inside another program's JVM, refuses it.

The engine and the JVM a cache was trained for are hashed into its name, as engine-<hex>.aot, so a changed engine or an upgraded JDK trains a new one and the one that no longer fits is removed. help, skill, configuration and properties only print, so they neither train nor use a cache. The daemon keeps a warm JIT the cache does not, so it stays ahead in a tight edit-build loop on a large project; where builds are frequent and small, or a machine builds many projects now and then, the cache is the better trade.

• Demo 6: Startup cost

Building & testing

The quality and packaging files these keys gate (checkstyle.xml, packaging.properties, and the like) are covered in Code quality & testing, Generating sources, Supply-chain features, and Packaging.

Dependencies & pinning

Repositories

Caching

Running & containers

Releasing

Read by the release target - see Publishing.

Read by the signing step - see Publishing. Naming any of them says the project signs its jar, and the build then stops rather than producing an unsigned one if the key store, the alias or the password location is missing.

Output & the execution engine

Built-in steps

A selector names a step by its identity. The build is a tree of these; the identities below are the ones you address on the command line. Each produces one output folder from its inputs, and its full behaviour is in the linked chapter.

Per module

Packaging

Wired by keys in packaging.properties - see Packaging.

Top level

The build, stage, export, release, and pin modules are the top-level targets in the table above; each layout wires the maven and/or modular staging and export sub-steps under them. When a project names plugins of the whole project, build also holds preprocess/custom/<name>, which runs before any module is built, and postprocess/transform/<name> and postprocess/inspect/<name>, which run over every module after it is built, while stage holds transform/<name> and inspect/<name> - with the stock staging then in staged/<tree> and each stage/<tree> merging it with what the transforms of stage added - export and release hold custom/<name> beside their own steps, and the top-level plugin holds a plugin of the hook point plugin as plugin/<name>, run only when named; stage/project holds what the transforms placed in the project (see Extending the build).

Source declarations

Everything a module declares about its build is a Javadoc tag on module-info.java - or, in the maven layout, the POM equivalent named beside it. Tags are read from the module's documentation comment in either form - the traditional /** ... */ and the Markdown /// of JEP 467 - and pin writes back in whichever form the comment already uses. This is the whole vocabulary: