Adding dependencies

Exposed is split into specific modules that give you the flexibility to only use the modules you need. In this topic you'll learn what these modules are and how to add module dependencies to an existing Gradle/Maven project.

Configure the repository

Exposed modules are available from the Maven Central repository. To use them, add the appropriate dependency into your repository mapping:

    repositories {
        mavenCentral()
    }
    

The Maven Central repository is enabled by default for Maven users.

    repositories {
        mavenCentral()
    }
    

Add dependencies

At a minimum, an Exposed application requires the core module and exactly one transport module. The examples below show the smallest possible dependency sets for common setups:

    dependencies {
        implementation("org.jetbrains.exposed:exposed-core:1.6.0")
        implementation("org.jetbrains.exposed:exposed-jdbc:1.6.0")
        implementation("org.jetbrains.exposed:exposed-dao:1.6.0") // Optional
    }
    

        <dependencies>
            <dependency>
                <groupId>org.jetbrains.exposed</groupId>
                <artifactId>exposed-core</artifactId>
                <version>1.6.0</version>
            </dependency>
            <dependency>
                <groupId>org.jetbrains.exposed</groupId>
                <artifactId>exposed-jdbc</artifactId>
                <version>1.6.0</version>
            </dependency>
            <dependency>
                <groupId>org.jetbrains.exposed</groupId>
                <artifactId>exposed-dao</artifactId>
                <version>1.6.0</version>
            </dependency>
        </dependencies>
    
    

    dependencies {
        implementation "org.jetbrains.exposed:exposed-core:1.6.0"
        implementation "org.jetbrains.exposed:exposed-jdbc:1.6.0"
        implementation "org.jetbrains.exposed:exposed-dao:1.6.0" //optional
    }
    

Use a version catalog

If you use a Gradle version catalog, you can import the published exposed-version-catalog instead of listing each Exposed coordinate by hand. The catalog provides a type-safe accessor for every Exposed module and keeps their versions aligned.

Import the catalog in your settings.gradle.kts:

    dependencyResolutionManagement {
        repositories {
            mavenCentral()
        }
        versionCatalogs {
            create("exposedLibs") {
                from("org.jetbrains.exposed:exposed-version-catalog:1.6.0")
            }
        }
    }
    

    dependencyResolutionManagement {
        repositories {
            mavenCentral()
        }
        versionCatalogs {
            create("exposedLibs") {
                from("org.jetbrains.exposed:exposed-version-catalog:1.6.0")
            }
        }
    }
    

Then reference the modules through the catalog accessors in your Gradle build script:

    dependencies {
        implementation(exposedLibs.core)
        implementation(exposedLibs.jdbc)
        implementation(exposedLibs.dao) // Optional
    }
    

    dependencies {
        implementation exposedLibs.core
        implementation exposedLibs.jdbc
        implementation exposedLibs.dao // Optional
    }
    

The accessor for each module is its name with the exposed- prefix removed and any dashes turned into nested accessors. For example, exposed-kotlin-datetime becomes exposedLibs.kotlin.datetime.

All modules share the same exposed version, which you can override for the whole catalog in one place:

versionCatalogs {
    create("exposedLibs") {
        from("org.jetbrains.exposed:exposed-version-catalog:1.6.0")
        version("exposed", "1.6.0")
    }
}

Modules

Exposed consists of multiple modules, grouped into the following categories:

Core module
Transport modules
Database access modules
Extension modules

Core module

To use Exposed in your application, you need the following core module:

Module	Function
`exposed-core`	Provides the foundational components and abstractions needed to work with databases in a type-safe manner and includes the Domain-Specific Language (DSL) API

Transport modules

Transport modules define how Exposed communicates with the database and are mutually exclusive.

Module	Function
`exposed-jdbc`	Provides support for Java Database Connectivity (JDBC) with a transport-level implementation based on the Java JDBC API
`exposed-r2dbc`	Provides support for Reactive Relational Database Connectivity (R2DBC)

Database access modules

Exposed offers optional database access modules that build on top of exposed-core and provide higher-level abstractions for working with database data. Pick the one matching your transport module:

Module	Function
`exposed-dao`	Provides the Data Access Object (DAO) API. Requires `exposed-jdbc` and is not compatible with `exposed-r2dbc`.
`exposed-dao-r2dbc`	Provides the DAO API for R2DBC. Requires `exposed-r2dbc`, and is an experimental preview whose API may still change between releases.

Extension modules

The following modules extend Exposed's capabilities, allowing you to work with specific data types, encryption, and date-time handling:

Module	Function
`exposed-crypt`	Provides additional column types to store encrypted data in the database and encode/decode it on the client-side, as well as one-way hashed data such as passwords
`exposed-java-time`	Date-time extensions based on the Java 8 Time API
`exposed-jodatime`	Date-time extensions based on the Joda-Time library
`exposed-json`	JSON and JSONB data type extensions
`exposed-kotlin-datetime`	Date-time extensions based on the `kotlinx-datetime` library
`exposed-money`	Extensions to support `MonetaryAmount` from the JavaMoney API
`exposed-spring-boot-starter`	A starter for Spring Boot 3 to utilize Exposed as the ORM
`exposed-spring-boot4-starter`	A starter for Spring Boot 4 to utilize Exposed as the ORM
`spring-transaction`	Transaction manager that builds on top of the standard transaction workflow from Spring Framework 6
`spring7-transaction`	Transaction manager that builds on top of the standard transaction workflow from Spring Framework 7
`exposed-migration-core`	Provides core common functionality for database schema migrations
`exposed-migration-jdbc`	Provides utilities to support database schema migrations, with a reliance on a JDBC driver
`exposed-migration-r2dbc`	Provides utilities to support database schema migrations, with a reliance on a R2DBC driver

Add a JDBC/R2DBC driver

You also need a JDBC or R2DBC driver for the database system you are using. For example, the following dependency adds a JDBC driver for the H2 database:

    dependencies {
        implementation("com.h2database:h2:2.4.240")
    }
    

    <dependencies>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>2.4.240</version>
        </dependency>
    </dependencies>
    

    dependencies {
        implementation "com.h2database:h2:2.4.240"
    }
    

Add a logging dependency

To be able to see logs from StdOutSqlLogger, add a logging dependency:

    dependencies {
        // Minimal logging (no output)
        implementation("org.slf4j:slf4j-nop:2.0.9")
        // Full-featured logging using Logback
        implementation("ch.qos.logback:logback-classic:1.5.20")
    }
    

        <!-- Minimal logging (no output) -->
        <dependencies>
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-nop</artifactId>
                <version>2.0.9</version>
            </dependency>
        </dependencies>
        <!-- Full-featured logging using Logback -->
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>1.5.20</version>
        </dependency>
        
    

        dependencies {
            // Minimal logging (no output)
            implementation("org.slf4j:slf4j-nop:2.0.9")
            // Full-featured logging using Logback
            implementation("ch.qos.logback:logback-classic:1.5.20")
        }
    

16 October 2026