Unresolved reference 'libs'

Help/Discuss
1

Hello,

I’ve created a java-application project via gradle cmd line using JDK 25. I’ve made some minor modifications to the sub projects ‘app’, ‘list’, and ‘utilities’. I also added the following to \gradle\libs.versions.toml

[versions]
commonsTextVersion = "1.15"
junitVersion = "6.1"

[libraries]
commons-text = { module = "org.apache.commons:commons-text", version.ref = "commonsTextVersion" }
junit-jupiter = { module = "org.junit.jupiter:junit-jupiter", version.ref = "junitVersion" }

and the \buildSrc\src\main\kotlin\buildlogic.java-common-conventions.gradle.kts was updated to:

plugins {
	`java-library`
	`distribution`
	`eclipse`
}
dependencies {
	constraints {
		// Define dependency versions as constraints
// original
//		implementation("org.apache.commons:commons-text:1.14.0")
// using val declarations in same gradle.kts file
//		implementation("org.apache.commons:commons-text:${commonsTextVersion}")
// FAILED 'Unresolved reference 'libs'
		implementation(libs.commons.text)
	}

	// Use JUnit Jupiter for testing.
//	testImplementation("org.junit.jupiter:junit-jupiter:6.0.1")
//	testImplementation("org.junit.jupiter:junit-jupiter:${junitVersion}")
// FAILED 'Unresolved reference 'libs'
	testImplementation(libs.junit.jupiter )

	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

both the build.gradle.ktsand settings.gradle.ktswithin buildSrc are untouched.

When I run any gradle task clean/run/build, I get 'Unresolved references ‘libs’. Searching on Google, didn’t find anything useful. Is it possible to use to libsin the buildlogic*.gradle.kts or I can only use them in build.gradle.kts in the root of the main project? I’d like to declare a list versions in one place and use partial subset in each of my sub-projects. I thought the libs.versions.toml would allow that especially the bundles section seems very handy and tidy.

Thanks,
Tommy

[EDIT] Here’s the error:

d:\Dev\_projects_\java\vu>%GRADLE_HOME%\bin\gradle clean

> Task :buildSrc:compileKotlin FAILED
e: file:///D:/Dev/_projects_/java/vu/buildSrc/src/main/kotlin/buildlogic.java-common-conventions.gradle.kts:118:18 Unresolved reference 'libs'.
e: file:///D:/Dev/_projects_/java/vu/buildSrc/src/main/kotlin/buildlogic.java-common-conventions.gradle.kts:124:21 Unresolved reference 'libs'.

[Incubating] Problems report is available at: file:///D:/Dev/_projects_/java/vu/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildSrc:compileKotlin' (registered by plugin class 'org.jetbrains.kotlin.gradle.plugin.KotlinPluginWrapper').
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.btapi.BuildToolsApiCompilationWork
   > Compilation error. See log for more details

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights from a Build Scan (powered by Develocity).
> Get more help at https://help.gradle.org.

BUILD FAILED in 2s
8 actionable tasks: 2 executed, 6 up-to-date
2

Due to the nature of the version catalog feature, included builds, and the Kotlin DSL type-safe accessors, the libs... accessors are not available out of the box in precompiled Kotlin DSL script plugins.

Version catalogs are defined by the build where the plugin is applied to.

A plugin built in an included build does inherently not know where it is applied to.

Type-safe accessors for Kotlin DSL are only generated for things Gradle knows for sure are present at runtime, which it cannot know, as it does not know what version catalog will be available.

See also this issue about it: Make generated type-safe version catalogs accessors accessible from precompiled script plugins · Issue #15383 · gradle/gradle · GitHub

There are also various work-arounds or alternatives mentioned.

For example the official way, using the string-y VersionCatalogs extension, or a hack-around by me to make the accessors usable, or a plugin that generates similar accessors, …

3

Thank you. Your suggestions in the ‘issue’ at github works nicely!