Skip to content

Distribution Flavors

Petrus Pradella edited this page Jun 26, 2026 · 6 revisions

Distribution Flavors

What this page covers: the two published flavors — everydatabase-core and everydatabase-libby — what each one puts on your classpath, how libby's loadAll and granular bundles work, and how to override or exclude dependencies. Same code, same API everywhere — they differ only in how the dependency set reaches your classpath. For the actual version numbers, see Dependency Versions & Overrides.

📌 Note — pick exactly one flavor. Both carry the same dependency set by default (HikariCP, Jackson databind + yaml, the MongoDB driver, H2, and the MySQL + PostgreSQL JDBC drivers).


The 30-second decision

repositories {
    maven { url 'https://maven.petrus.dev/public' }
    mavenCentral()
}

dependencies {
    // RECOMMENDED — full deps as normal POM dependencies; override any version yourself:
    implementation 'br.com.finalcraft.everydatabase:everydatabase-core:1.0.4'

    // OR runtime download — tiny jar, the same set is fetched at runtime via Libby:
    //implementation 'br.com.finalcraft.everydatabase:everydatabase-libby:1.0.4'
}

🧭 Decisioncore when you control your own build and want to override versions the normal way (the default for almost everyone). libby when you want the smallest possible artifact and don't mind a one-time runtime download on first launch.


everydatabase-core — the recommended flavor

The library with every backend dependency declared as an ordinary POM dependency. It works out of the box, and you keep full control through standard dependency management. The POM scopes encode the API boundary:

Scope Dependencies Why
api (compile) jackson-databind, mongodb-driver-sync their types appear in public signatures (JacksonJsonCodec(Class, ObjectMapper), MongoMigration)
implementation jackson-dataformat-yaml, HikariCP internal machinery
runtimeOnly H2, mysql-connector-j, postgresql JDBC drivers — needed at runtime, not at compile time

The published everydatabase-core POM therefore carries the full runtime set — that's the point: it's the recommended flavor, and you downgrade or upgrade any of them via normal dependency management.

📌 Noteslf4j-api is compileOnly by design: the library must be shadeable without dragging a logging framework. Its runtime presence is probed reflectively (see Logging & Diagnostics). Don't promote it to implementation.

Overriding a version

Gradle picks the highest version by default; declare your own to change it. Append !! to force a downgrade. In Maven, your nearest declaration always wins.

dependencies {
    implementation 'br.com.finalcraft.everydatabase:everydatabase-core:1.0.4'

    implementation 'com.fasterxml.jackson.core:jackson-databind:2.17.2'   // upgrade Jackson
    runtimeOnly    'com.mysql:mysql-connector-j:8.4.0!!'                  // force-downgrade the MySQL driver
}

Excluding what you don't use

// Only target SQL? Drop the Mongo driver entirely:
implementation('br.com.finalcraft.everydatabase:everydatabase-core:1.0.4') {
    exclude group: 'org.mongodb'
}

⚠️ Gotcha — the H2 and HikariCP defaults are pinned to the last Java-8-compatible lines (H2 1.4.200, HikariCP 4.x). On Java 11+ you may override to H2 2.x / HikariCP 5.x, but H2 1.x and 2.x have incompatible database file formats — never swap the major over an existing embedded-file database. The exact numbers and override recipes live on Dependency Versions & Overrides.


everydatabase-libby — runtime download

everydatabase-core plus a small coordinator (package br.com.finalcraft.everydatabase.libby) that downloads the canonical, non-relocated libraries at runtime via Libby. Your jar stays tiny, and the POM depends on core with the transitive set excluded, so nothing heavy enters your build-time graph either.

📌 Note — Libby does not resolve transitive dependencies, so EveryDatabaseDependencies enumerates the full flat dependency tree of everydatabase-core explicitly. The versions there must stay in sync with the project's version catalog (gradle/libs.versions.toml).

Bootstrap it in your plugin's onLoad (or earliest bootstrap), before touching any storage class:

import br.com.finalcraft.everydatabase.libby.DependencyManager;
import br.com.finalcraft.everydatabase.libby.EveryDatabaseDependencies;

@Override
public void onLoad() {
    DependencyManager manager = new DependencyManager("MyPlugin", getDataFolder(), "libs");
    EveryDatabaseDependencies.loadAll(manager);   // HikariCP, Jackson, Mongo driver, H2 + both JDBC drivers
    // ... Storages.createH2(...), Storages.createMongo(...), etc. now work
}

loadAll vs the granular bundles

loadAll(manager) covers every backend: the Jackson JSON + YAML stacks, the SQL pool stack (HikariCP + slf4j-api), the embedded H2 engine, the MongoDB driver, and the JDBC drivers for MySQL/MariaDB and PostgreSQL. Slimmer setups can compose narrower bundles instead — re-listing a jar across bundles is harmless (already-downloaded files are reused, already-added classpath URLs ignored):

Bundle Loads
loadAll(manager) everything below, combined
loadJacksonJson(manager) jackson-core, jackson-annotations, jackson-databind — what JacksonJsonCodec needs
loadJacksonYaml(manager) the JSON stack plus jackson-dataformat-yaml + snakeyaml
loadSql(manager) HikariCP + slf4j-api (the shared SQL pool stack)
loadH2(manager) the SQL pool stack plus the H2 engine (driver built in)
loadMongo(manager) mongodb-driver-sync + -core + bson + bson-record-codec
loadMySqlDriver(manager) just com.mysql:mysql-connector-j
loadPostgresDriver(manager) just org.postgresql:postgresql
// Example slim setup: SQL-only against PostgreSQL, no Mongo, no YAML.
EveryDatabaseDependencies.loadJacksonJson(manager);   // codec
EveryDatabaseDependencies.loadSql(manager);           // HikariCP + slf4j-api
EveryDatabaseDependencies.loadPostgresDriver(manager);

📌 Noteeverydatabase-libby itself depends on net.byteflux:libby-core, resolved from https://repo.alessiodp.com/releases/. Add that repository to your build alongside the Maven repo above.

⚠️ Gotcha — the JDBC drivers ship in loadAll by default. If you compose granular bundles instead (e.g. loadSql), the driver is not included — pull it explicitly with loadMySqlDriver / loadPostgresDriver, or rely on a host-provided driver. loadSql gives you the pool, not the driver.


At a glance

core libby
Deps reach you via normal POM runtime download
Override versions? ✅ (dependency mgmt) ✅ (edit the bundle calls)
Transitive footprint in your build full none
MySQL/MariaDB driver POM dep (overridable) in loadAll (or loadMySqlDriver)
Needs a first-run download no yes
Best for most projects smallest artifact

📌 Note — the libby flavor's LibbySmokeTest exercises the coordinator with a recording fake (no network). See Running the Tests.


A note on the MySQL driver and GPL

mysql-connector-j is GPLv2 (with the Universal FOSS Exception). This project never redistributes it inside its own artifacts: core references it only as POM metadata (the end user's build resolves it), and libby downloads it from Maven Central on the end user's machine — neither is redistribution. So you always get the MySQL/MariaDB driver, and the GPL terms never attach to EveryDatabase itself.


See also

Clone this wiki locally