EN · DE · RU · FR · ES

#1872: build.gradle.kts (projectforge-common)

projectforge-common/build.gradle.kts Gradle build configuration — projectforge-common module, projectforge-common/build.gradle.kts 93 lines · 66 code · 14 comments · 13 blank
Gradle Kotlin DSL build file for the foundational projectforge-common library module. Configures the Kotlin JVM plugin with Java 17 target, JUnit 5 Platform test execution, and a comprehensive set of API dependencies including logging frameworks (SLF4J, Logback, Log4j2-to-SLF4J bridge), Apache Commons libraries, Kotlin stdlib/reflect, and Zip4j for ZIP operations. Contains a commented-out custom Gradle task for Git properties generation.

Architecture

Plugin Configuration

PluginPurpose
buildlogic.pf-module-conventionsCustom ProjectForge Gradle convention plugin (defined in buildSrc/) — applies shared build logic across all modules (Java compilation settings, repository configuration, code quality checks)
org.jetbrains.kotlin.jvmKotlin JVM compiler plugin — enables Kotlin compilation alongside Java sources

Kotlin Compilation Settings

tasks.withType<KotlinCompile> {
    compilerOptions {
        jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17)
    }
}

All Kotlin source is compiled to Java 17 bytecode. This aligns with the project's Java 17 baseline (also reflected in the DatabaseDialect enum referencing Hibernate 6 dialects and Jakarta EE namespace usage elsewhere).

Test Configuration

tasks.withType<Test> {
    useJUnitPlatform()
    testLogging {
        events("PASSED", "FAILED", "SKIPPED", "STANDARD_OUT", "STANDARD_ERROR")
        exceptionFormat = org.gradle.api.tasks.testing.logging.TestExceptionFormat.FULL
        showStandardStreams = true
    }
}

Uses JUnit Platform (JUnit 5) for test discovery and execution. Test logging is configured for detailed output showing all test events, full exception stacktraces, and standard output/error streams — useful for debugging test failures in CI/CD environments.

Dependencies (API scope)

DependencyPurposeVersion Source
org.slf4j:slf4j-apiSLF4J logging facade APIlibs.org.slf4j.api (version catalog)
org.slf4j:jul-to-slf4jBridges java.util.logging to SLF4Jlibs.org.slf4j.jul.to.slf4j
ch.qos.logback:logback-classicLogback logging implementationlibs.ch.qos.logback.classic
org.apache.logging.log4j:log4j-apiLog4j2 API (for bridging)libs.org.apache.logging.log4j.api
org.apache.logging.log4j:log4j-to-slf4jBridges Log4j2 to SLF4Jlibs.org.apache.logging.log4j.to.slf4j
commons-beanutils:commons-beanutilsApache Commons BeanUtils (property introspection)libs.commons.beanutils
org.jetbrains.kotlin:kotlin-stdlibKotlin standard librarylibs.org.jetbrains.kotlin.stdlib
org.jetbrains.kotlin:kotlin-reflectKotlin reflection librarylibs.org.jetbrains.kotlin.reflect
org.apache.commons:commons-collections4Apache Commons Collections 4version catalog
org.apache.commons:commons-lang3Apache Commons Lang 3 (StringUtils, etc.)version catalog
net.lingala.zip4j:zip4jZIP archive library (compression, extraction)libs.net.lingala.zip4j.zip4j

Test Dependencies

DependencyScope
project(":projectforge-commons-test")Test utility module providing shared test infrastructure
org.mockito:mockito-coreMockito mocking framework for unit tests

Logging Architecture

The logging stack is carefully layered:

  1. Application code uses SLF4J API (the facade)
  2. Logback is the actual logging implementation
  3. java.util.logging → SLF4J bridge catches JDK logger output from third-party libraries
  4. Log4j2 → SLF4J bridge catches Log4j2 logger output from third-party libraries

This ensures that ALL log output (regardless of which logging API a library uses) is routed through SLF4J to Logback, enabling centralized log configuration via logback-spring.xml.

Commented-Out: Git Properties Generator

A large commented-out block shows a custom Gradle task (generateGitProperties) that used the org.ajoberstar.grgit plugin to generate git.properties with build metadata (branch, commit ID, build time, dirty flag). The Grgit plugin dependency is also commented out (//id("org.ajoberstar.grgit") version "5.3.0"). This suggests the Git properties functionality was migrated to another module or replaced by a different mechanism.

The use of a Gradle version catalog (libs.versions.toml in the gradle/ directory) centralizes dependency version management. The libs.<alias> syntax references entries from the TOML catalog, making version upgrades a single-point change across all modules.

Git History

69441cecd ZipMode and ZipUtils moved to common (for availability in scripts)
e21feaa61 Gradle games...
1d2849687 WIP: Gradle dependencies, (all tests OK)
98393fe4c WIP: gradle...
ca9851ba0 WIP: gradle...
41e2d26e7 WIP: gradle...
e31db0a87 WIP: gradle...
2ab2292fb WIP: gradle...