Back to Exposed

Adding Dependencies

documentation-website/Writerside/topics/Adding-dependencies.md

1.5.013.6 KB
Original Source
<show-structure for="chapter,procedure" depth="2"/>

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:

<tabs> <tab title="Kotlin Gradle"> <code-block lang="kotlin"> repositories { mavenCentral() } </code-block> </tab> <tab title="Maven"> The Maven Central repository is enabled by default for Maven users. </tab> <tab title="Groovy Gradle"> <code-block lang="groovy"> repositories { mavenCentral() } </code-block> </tab> </tabs>

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:

<tabs> <tab title="Kotlin Gradle"> <code-block lang="kotlin"> dependencies { implementation("org.jetbrains.exposed:exposed-core:%exposed_version%") implementation("org.jetbrains.exposed:exposed-jdbc:%exposed_version%") implementation("org.jetbrains.exposed:exposed-dao:%exposed_version%") // Optional } </code-block> </tab> <tab title="Maven"> <code-block lang="xml"><![CDATA[ <dependencies> <dependency> <groupId>org.jetbrains.exposed</groupId> <artifactId>exposed-core</artifactId> <version>%exposed_version%</version> </dependency> <dependency> <groupId>org.jetbrains.exposed</groupId> <artifactId>exposed-jdbc</artifactId> <version>%exposed_version%</version> </dependency> <dependency> <groupId>org.jetbrains.exposed</groupId> <artifactId>exposed-dao</artifactId> <version>%exposed_version%</version> </dependency> </dependencies> ]]> </code-block> </tab> <tab title="Groovy Gradle"> <code-block lang="groovy"> dependencies { implementation "org.jetbrains.exposed:exposed-core:%exposed_version%" implementation "org.jetbrains.exposed:exposed-jdbc:%exposed_version%" implementation "org.jetbrains.exposed:exposed-dao:%exposed_version%" //optional } </code-block> </tab> </tabs>

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:

<tabs> <tab title="Kotlin Gradle"> <code-block lang="kotlin"> dependencyResolutionManagement { repositories { mavenCentral() } versionCatalogs { create("exposedLibs") { from("org.jetbrains.exposed:exposed-version-catalog:%exposed_version%") } } } </code-block> </tab> <tab title="Groovy Gradle"> <code-block lang="groovy"> dependencyResolutionManagement { repositories { mavenCentral() } versionCatalogs { create("exposedLibs") { from("org.jetbrains.exposed:exposed-version-catalog:%exposed_version%") } } } </code-block> </tab> </tabs>

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

<tabs> <tab title="Kotlin Gradle"> <code-block lang="kotlin"> dependencies { implementation(exposedLibs.core) implementation(exposedLibs.jdbc) implementation(exposedLibs.dao) // Optional } </code-block> </tab> <tab title="Groovy Gradle"> <code-block lang="groovy"> dependencies { implementation exposedLibs.core implementation exposedLibs.jdbc implementation exposedLibs.dao // Optional } </code-block> </tab> </tabs>

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.

{style="note"}

Version catalogs are a Gradle feature. Maven users should declare dependencies directly, as shown above. {style="note"}

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

<code-block lang="kotlin"> versionCatalogs { create("exposedLibs") { from("org.jetbrains.exposed:exposed-version-catalog:%exposed_version%") version("exposed", "%exposed_version%") } } </code-block>

The catalog is imported under the name exposedLibs rather than exposed to avoid a clash with the , which registers a project extension named exposed. If you don't apply that plugin, you can name the catalog exposed and use accessors such as exposed.core.

Modules

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

Core module

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

ModuleFunction
exposed-coreProvides 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.

ModuleFunction
exposed-jdbcProvides support for Java Database Connectivity (JDBC) with a transport-level implementation based on the Java JDBC API
exposed-r2dbcProvides support for Reactive Relational Database Connectivity (R2DBC)

You only need one transport module – either exposed-jdbc or exposed-r2dbc, not both. {style="note"}

Database access module

Exposed offers an optional database access module that builds on top of exposed-core and provides higher-level abstractions for working with database data:

ModuleFunction
exposed-daoProvides the Data Access Object (DAO) API.
Requires exposed-jdbc and is not compatible with exposed-r2dbc.

Extension modules

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

ModuleFunction
exposed-cryptProvides 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-timeDate-time extensions based on the Java 8 Time API
exposed-jodatimeDate-time extensions based on the Joda-Time library
exposed-jsonJSON and JSONB data type extensions
exposed-kotlin-datetimeDate-time extensions based on the kotlinx-datetime library
exposed-moneyExtensions to support MonetaryAmount from the JavaMoney API
exposed-spring-boot-starterA starter for Spring Boot 3 to utilize Exposed as the ORM
exposed-spring-boot4-starterA starter for Spring Boot 4 to utilize Exposed as the ORM
spring-transactionTransaction manager that builds on top of the standard transaction workflow from Spring Framework 6
spring7-transactionTransaction manager that builds on top of the standard transaction workflow from Spring Framework 7
exposed-migration-coreProvides core common functionality for database schema migrations
exposed-migration-jdbcProvides utilities to support database schema migrations, with a reliance on a JDBC driver
exposed-migration-r2dbcProvides 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:

<tabs> <tab title="Kotlin Gradle"> <code-block lang="kotlin"> dependencies { implementation("com.h2database:h2:%h2_db_version%") } </code-block> </tab> <tab title="Maven"> <code-block lang="xml"><![CDATA[ <dependencies> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>2.4.240</version> </dependency> </dependencies> ]]> </code-block> </tab> <tab title="Groovy Gradle"> <code-block lang="groovy"> dependencies { implementation "com.h2database:h2:%h2_db_version%" } </code-block> </tab> </tabs>

For the complete list of supported databases and their corresponding driver dependencies, see .

Add a logging dependency

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

<tabs> <tab title="Kotlin Gradle"> <code-block lang="kotlin"> dependencies { // Minimal logging (no output) implementation("org.slf4j:slf4j-nop:%slf4j_version%") // Full-featured logging using Logback implementation("ch.qos.logback:logback-classic:%logback_version%") } </code-block> </tab> <tab title="Maven"> <code-block lang="xml"><![CDATA[ <!-- Minimal logging (no output) --> <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-nop</artifactId> <version>%slf4j_version%</version> </dependency> </dependencies> <!-- Full-featured logging using Logback --> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>%logback_version%</version> </dependency> ]]> </code-block> </tab> <tab title="Groovy Gradle"> <code-block lang="groovy"> dependencies { // Minimal logging (no output) implementation("org.slf4j:slf4j-nop:%slf4j_version%") // Full-featured logging using Logback implementation("ch.qos.logback:logback-classic:%logback_version%") } </code-block> </tab> </tabs>

For more information on why a logging dependency is needed, see the SLF4J Documentation.