Vidocq chooses the application’s main itself whenever the application is handed over as a path rather than as a module to launch: mvn vidocq:run, vidocq:dev with -Dvidocq.dev.hotReload=false, and the packaged launcher of an application that has no @VidocqMain trampoline. All three pass -Dvidocq.app.main, and the runtime reaches that main by reflection, inside the application layer. (With a trampoline the script launches --module app/acme.App and the JVM launcher makes the choice; vidocq:dev’s hot-reload loop, the default, ignores `vidocq.app.main on purpose and reboots the layer instead.)

The choice accepts the four shapes the Java SE launcher accepts since Java 25 (JEP 512), and, like the launcher, never requires public:

Selection follows the launcher’s own algorithm, and its consequences are worth knowing:

This matters in an IDE on JDK 25: the inspection that flags the public of a main as an unnecessary modifier is right, and following it no longer breaks the launch. For an application module the layer defines, the controller exports and opens the package of the class named by vidocq.app.main and the package of the class that declares the selected method — two different packages, in two different modules, as soon as the main is inherited.

The identity line is Vidocq <version>, followed by details only for a snapshot or a build from a modified working tree:

Times are UTC, to the second. A directory of classes shows where the classes come from rather than a commit: an IDE recompiles without Maven, so its build identity file and its version may be older than the classes, hence the ?.

The context line is Java <version> (<vendor>) | <mode> (<reason>) | debug <address> | devconsole <address> | <application> <version>:

Both lines stay within 80 columns. For the context line, what is given up goes in this order: the JVM vendor, then the segments of a module name are abbreviated (i.v.t.l.mcptimeserver), then the name is cut with …​ — always before the application version — then the dev console NEW, and the name comes back whole if it then fits, then the debugger, then the reason of the launch mode, and with it the whole segment when the mode is a prod that no signal proves; the whole line is cut last. The vendor goes first because the line is read to know where the process runs and how to attach to it: 19 columns of (Eclipse Adoptium) never cost the address of a debugger, nor the mode and the reason it was read from. A long directory path drops its last Maven build label before being cut. The single INFO line is never cut: it carries the mode, its reason, the debugger and the dev console whatever their length.

The Vidocq bricks have their own versions. When a brick (Vauban, Chappe, Cassini, …​) has another version than the runtime, was built from a modified tree, or is a snapshot without a commit, one more INFO record lists them:

Vidocq says which of dev, test and prod it is running in, and in parentheses the signal it read it from — the claim and its evidence, never one without the other. It is an observation, not a switch: the container, the configuration and the extensions' lifecycle are the same in every mode. It decides what is printed — the art of the banner, and the default level of the startup report — so that a log or a screenshot says what the launch was. An extension reads it with ExtensionContext.launchMode() NEW to offer what only makes sense in development (Reading the launch mode).

The first signal found wins:

A profile that is no mode (staging) is not a signal: the detection goes on without it. vidocq.launch.mode=auto NEW, the default, lets the detection decide too; any other value that names no mode is reported as VIDOCQ-CFG-001 — invalid value and does the same.

prod is the only mode that rests on an absence, and it never shows without saying so: when the context line is too narrow for prod (no dev or test signal), the whole segment goes rather than leave a bare prod claiming more than is known.

Reading the archives is bounded: at most four of them, their shape is a string comparison, and only one of them has its parents probed for a build file — a handful of stat calls, once per boot: every reload of the dev loop reads its launch again. Nothing in the resolution throws: a probe that fails is a signal that was not found, and the worst case is the prod above.

A terminal means that System.console() exists and isTerminal() is true: redirecting standard input or standard output turns the art off. A dev launch is a mode of dev read from a deliberate signal — vidocq.launch.mode, a profile, the dev reload loop, or IntelliJ’s Run console, which is not a terminal and is what shows the art on an IDE Run. A dev read from the shape of a build tree does not show the art without a terminal: a piped CI job runs out of target/classes too.

The banner is printed once per JVM: a hot reload or a second deployment in the same JVM prints nothing more. It never fails the boot. Its logger, io.vidocq.runtime.core.banner.StartupBanner, can be silenced through the logging configuration.

Code that embeds Vidocq and owns its standard output (a tool whose output is data, a CLI plugin) sets the mode itself; this wins over the configuration:

Like every key, they can be set with -D, an environment variable (VIDOCQ_BANNER_MODE), vidocq.properties or a profile (%dev.vidocq.banner.mode). There is no vidocq.banner.enabled: the startup audit reports it with the known keys of the namespace.

On a terminal or in IntelliJ’s Run console, the art is cyan, Vidocq <version> bold, the build details yellow and the context line faint. The policy is the one of the console logs: a non-empty NO_COLOR environment variable always wins, vidocq.console.color=always or never forces the choice, and auto needs TERM other than dumb and IntelliJ’s Run console or a terminal on an operating system other than Windows. Output piped to a file or a container log never carries escape sequences.

A vidocq-banner.txt file at the root of the application’s resources replaces the art, with no configuration; vidocq.banner.location points to another file. The file is read as UTF-8 through the context class loader, as vidocq.properties is. Its lines are printed as they are, after placeholder substitution:

An unknown placeholder becomes empty, and a ${ without its closing brace on the same line is printed as is. Vidocq appends its identity and context lines after the file, so the version survives any custom banner, unless the file places ${vidocq.identity} itself.

Every jar built with io.vidocq:vidocq-parent (Vidocq, Vauban, Cassini, Chappe, and the applications created by vidocq create, through vidocq-runtime-parent) carries a build identity file, META-INF/vidocq/build-info/<artifactId>.properties, written by git-commit-id-maven-plugin at the initialize phase:

To find the commit a snapshot was built from, read the file in the jar, then look the commit up in the repository of that brick:

The contributed sections follow the sections of the core: first those of the extensions that contribute one, in the order they started, then those of the other libraries. The report is made of what the boot already holds — the layer’s resolved modules, the loaded extensions, the configuration sources — and its own time is the report phase of the detailed report.

vidocq.startup.report chooses how much is printed: auto (the default), off, summary or detailed. An explicit level is honoured on every boot. auto follows the launch mode:

A dev launch shows everything once, then one line per section on every reload. An embedded deployment boots hundreds of times in one JVM, so it prints no report unless vidocq.startup.report asks for one — the banner is reduced to one line there too.

While the dev console is on NEW, the contributors are given the detailed level whatever the report prints, so that the console has every row even on a reload that logs the summary; what the log prints still follows the level above.

off only removes the report. The contributors are still called, and every anomaly is still logged as its own warning. A value that is none of the four is reported as VIDOCQ-CFG-001 — invalid value and read as auto. Like every key, it can be set with -D, an environment variable (VIDOCQ_STARTUP_REPORT) or vidocq.properties.

An anomaly is something wrong that does not stop the boot. Each one is its own WARNING record on the logger io.vidocq.startup.anomaly, logged the moment it is detected, its code first:

It is logged at every report level, off included, and before the report, so a boot that fails later still shows it, and a log pipeline can alert on its code. It is always one line: a line break or another control character in what it quotes, a configured value or a key name, becomes ?, so no anomaly can start a line that looks like another record. It is never cut. The report only recalls the codes, in its anomalies section. A library can report anomalies of its own, under its own codes, from its section of the report (Contributing to the startup report).

The core raises these codes.

A boot that fails, in configure() or in start(), logs one WARNING record on io.vidocq.startup before the exception goes on, at every report level: what was running, the time since the bootstrap was created, the exception class and the codes of the anomalies already logged. In a dev launch, the partial report follows in the same record, unless the report level is off:

What was running is a phase — configure, weaving, scan, beforeStart, build, extensions, audit, report — or, more precisely, the extension or the contributor it was calling: configure rest-cassini, beforeStart rest-cassini, onStart chappe-bootstrap, contributor mcp. The exception is the one that was thrown, untouched: not wrapped, nothing added to it, with its own stack trace. The contributors are not called when the boot fails before the report, since the container and the routes may be incomplete: a partial report has the sections of the core only.

The report of a boot that went well never fails it: if the report cannot be produced, one WARNING, Startup report skipped: …​, says why, and the boot goes on.

The report goes to logs that are shared, pasted into issues and kept. It prints names and counts, never what an application keeps to itself:

To hide the report, prefer vidocq.startup.report=off, which keeps everything else. Through the logging configuration, io.vidocq.startup.level=WARNING hides the report and keeps the warnings; OFF would silence the failure record and, since io.vidocq.startup.anomaly inherits the level of io.vidocq.startup, the anomalies as well.

[LEVEL][timestamp][thread][source] : message, one line per record:

Every level goes to standard output, flushed after each record: the logs stay in one stream, in order, with what the application prints.

Vidocq replaces the JDK’s default console handler first thing in Vidocq.main, in both Vidocq.run overloads and in VidocqBootstrap.create(), and only when the application has chosen nothing. The JDK default stays untouched when any of these holds:

An application that calls LogManager.readConfiguration after the boot still replaces Vidocq’s handler.

The first install happens before the configuration is loaded, so only -D system properties and environment variables (VIDOCQ_LOG_CONSOLE, VIDOCQ_CONSOLE_COLOR) are visible then. Once vidocq.properties is loaded, both keys apply from the configuration as well: vidocq.log.console=jdk there puts the JDK handler back before any extension is configured. An unknown value logs a warning and falls back to auto.

Only the level is coloured: ERROR bold red, WARN yellow, INFO green, CONF cyan, DEBUG and TRACE faint.

Vidocq never overrides a logging setup the application chose. To keep the JDK output or to use your own: