Hi :wave: I'd like to verify my understanding of h...
# community-support
m
Hi 👋 I'd like to verify my understanding of how runtimeClasspath relates to what actually ships to production, since we use it as the basis for our vulnerability-patching routines. Our setup We have a Kotlin/Ktor backend built with Gradle, using the application plugin. Dockerfile:
Copy code
FROM <jre-base-image>
COPY build/install/*/lib /lib
ENTRYPOINT ["java", "-cp", "/lib/*", "no.example.ApplicationKt"]
CI runs
./gradlew installDist
(among other tasks), which produces build/install/project-name/lib/ containing all jars that end up on the runtime classpath in the container. Our assumption When we audit dependencies for CVEs and decide what to pin via resolutionStrategy, we only care about what actually runs in production. We therefore use: ./gradlew dependencies --configuration runtimeClasspath | grep package Our reasoning: 1. The application plugin's installDist task copies the main source set's runtime classpath into build/install/name/lib/. 2. Other configurations (compileClasspath, testCompileClasspath, testRuntimeClasspath) are irrelevant for the deployed artifact — they may contain dependencies (e.g. transitive deps of test libraries like Testcontainers, Kotest extensions, etc.) that never reach the container. 3. Pinning versions for test-only transitive dependencies in resolutionStrategy adds noise to the build script and gives a false sense of security without affecting production risk. We verified this empirically: jars in build/install/name/lib/ match the contents of runtimeClasspath exactly (main source set's own jar + all resolved runtime dependencies), and test-only dependencies are not present. Questions 1. Is runtimeClasspath (the main source set's runtime classpath) the correct and canonical configuration to inspect when answering "what gets deployed to production" for an application-plugin + installDist + Docker setup? 2. Are there any edge cases where installDist/distTar/distZip would include jars not in runtimeClasspath, or exclude jars from runtimeClasspath? (e.g. configurations like runtimeOnly, developmentOnly, custom dependencies added to applicationDistribution, etc.) 3. Is there a more idiomatic Gradle command we should be using to answer this question — for example, inspecting the actual output of installDist directly, or some configuration like mainRuntimeClasspath that I'm not aware of? Any clarification or pointers to authoritative documentation would be appreciated. Thanks!