Build Setup

This page explains how Falco's Gradle build is put together: what the root project is for, how the modules relate to each other, and why the falco-bom module needs special handling throughout the build files. For version and release mechanics, see Versioning and Releases. For how the published artefacts reach a repository, see Publishing.

The root project has no sources

build.gradle.kts at the repository root applies no plugins of its own and carries no sources. This is deliberate: the root project exists only to hold the shared version and the configuration that every module inherits. Applying java-library there would create an empty, publishable falco artefact next to the real ones, which nobody wants to consume.

Modules

Module	Published	Kind
falco-anvil	yes	java-library
falco-light	yes	java-library
falco-instance	yes	java-library
falco-bom	yes	java-platform
falco-benchmarks	no	java-library + jmh
falco-demo	no	java-library

falco-anvil, falco-light and falco-instance are the three library modules the project actually ships. falco-bom is a Maven BOM pinning those three to one version (see Publishing). falco-benchmarks and falco-demo are tooling modules that are never published — see Benchmarks and Demo.

Applying plugins: why falco-bom is special-cased

The root build's subprojects block applies java-library and jacoco to every subproject except falco-bom:

configure(subprojects - project(":falco-bom")) {
    apply(plugin = "java-library")
    apply(plugin = "jacoco")
    ...
}

java-library and java-platform are mutually exclusive Gradle plugins — applying both to one project fails the build — and a java-platform project has no sources, so there is nothing for a toolchain, a compiler, or a test task to do there anyway. Subtracting falco-bom from the subproject list here, rather than guarding every apply() call inside the block with an if (name != "falco-bom"), keeps the block itself unaware that an exception exists: a plugin added to it later inherits the exclusion for free, and the diff against the pre-BOM version of the file is a one-line change of scope rather than a scattering of conditionals through the body.

java-platform itself is applied to falco-bom from the root build, in the same place java-library is applied to every other subproject:

project(":falco-bom") {
    apply(plugin = "java-platform")
}

This is not a style choice but an evaluation-order requirement. A subproject's own build script only runs after the root project's. If java-platform were applied inside falco-bom/build.gradle.kts instead, the javaPlatform software component it registers would not exist yet by the time the root script's publishing block (further down the same file) reaches for components["javaPlatform"] — the root script is still the one running at that point, and it needs the plugin already active to see the component it registers.

Group and version apply to every subproject, including falco-bom

subprojects {
    group = "net.onelitefeather"
    version = rootProject.version
}

This assignment sits outside the java-library configuration block precisely so it also reaches falco-bom. The BOM pins its siblings by project reference rather than by version string (see Publishing), and that only produces the right numbers in the generated POM if falco-bom carries the same version its siblings do.

No repositories are declared per-project

None of the module build files declares a repositories { } block. Repositories come exclusively from dependencyResolutionManagement in settings.gradle.kts. A project-level repositories block would take precedence over that central declaration, which would silently drop the OneLiteFeather repository that Minestom, Cyano, and the mycelium BOM are resolved from. See Dependency Management for what lives in that block.