Miha Markic
11/20/2025, 10:57 AMMiha Markic
11/20/2025, 10:59 AMMiha Markic
11/20/2025, 11:00 AMGabor Torok
11/20/2025, 4:30 PMruntimeClasspath works, i found something weird. we are on 8.11.1 , and running this task on different projects yield weird results:
tasks.register('printMyTestClasspath') {
dependsOn 'testClasses'
doLast {
def classpathUrls = sourceSets.test.runtimeClasspath.files
classpathUrls.each {
if (!it.toString().contains(".gradle")) { // to exclude external dependencies
println "classpath file: $it"
}
}
}
}
we have a setup where we have multiple builds depending on each other via includeBuild .
what's weird is that using the above task in show inconsistent results:
• sometime the main class directory is in there (build/classes/java/main) and sometime the jar file is in there ( build/libs/something-1.0.jar )
• similarly, this is the same for the included builds - i sometimes see the classes/java/main of the dependency project, and sometimes i see the jar
• on repeated executions the results seem to stay the same.
My questions are:
• What could cause this? The build.gradle files are very similar in our different builds, i did not find any indication of what could cause this difference (sure, i could be missing something.)
• Is this a bug? Or something that has been fixed in later versions?
• Are there any workarounds that I can use to get some consistency? I want to write tooling that loads the test classes with the class loader, and then checks stuff on them - but i am getting random errors, based on weather some projects classpath has the jar or the classes ...William Chong
11/20/2025, 9:19 PMCould not resolve all artifacts for configuration 'classpath'.> Could not find net.fabricmcfabric loom1.7.6. Searched in the following locations: - https://maven.fabricmc.net/net/fabricmc/fabric-loom/1.7.6/fabric-loom-1.7.6.pom - https://repo.maven.apache.org/maven2/net/fabricmc/fabric-loom/1.7.6/fab ric-loom-1.7.6.pom - https://plugins.gradle.org/m2/net/fabricmc/fabric-loom/1.7.6/fabric-loo m-1.7.6.pom Required by: buildscript of root project 'RealRender' * 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 generate a Build Scan (Powered by Develocity).
Get more help at https://help.gradle.org.BUILD FAILED in 6s and I tried using other version of gradle and it doesnt help I’m sorry for taking up your valuable time I know it might be a easy issue for you guys to solve. Thank you for your patience and guidance
Miha Markic
11/21/2025, 9:28 AMColton Idle
11/21/2025, 6:03 PMAdam
11/22/2025, 11:14 AMColton Idle
11/22/2025, 6:49 PMНиколай Клебан
11/23/2025, 10:12 AMJavi
11/24/2025, 9:37 AMimplementation configuration and looking for the dependencies there.Eli Graber
11/24/2025, 8:15 PMНиколай Клебан
11/25/2025, 9:18 AMplugins {} block.maikelvdh
11/25/2025, 12:00 PMincludeBuild() context? this to keep the mapping from module to project at its originColton Idle
11/26/2025, 2:43 AMid("org.jetbrains.kotlin.plugin.parcelize") . I converted it to an entry in my toml, and converted it to alias(libs.plugins.kotlin.parcelize) in my build file. but now it wont build UNLESS I go to root build.gradle and add ``alias(libs.plugins.kotlin.parcelize) apply false` `
Why is that needed when using version catalog... but when I just used id("org.jetbrains.kotlin.plugin.parcelize") it did not need the extra line in my root build.gradle (bonus points: how did it even work with id if I never declared the version of the plugin I wanted until i now had to add it in version catalog declaration)Sachin HR
11/26/2025, 3:06 PMMatei David
11/26/2025, 10:20 PM~/.gradle. What I currently do is to populate build/gradle with what I need, namely gradle.properties, some init.d/ scripts, and I point TestKit there with withTestKitDir(). This is mostly ok, except that the various Gradle distributions are downloaded in such test user home directories. This is annoying because it's slow the first time around, and also because these directories are not getting cleaned up. E.g. in 1 project after playing with only 9.2.0 and 9.2.1, I have almost 2GB of mostly generated Gradle jars and transforms. Is there a way to improve this? So basically, I don't care to isolate the Gradle artifacts and transforms from my primary Gradle user home, but I definitely want my user home properties and init scripts not to be visible in tests. Is there some way to achieve properties/init script isolation while also avoiding cache duplication?Gabor Torok
11/27/2025, 6:00 PMSystem.setProperty - and if i do, every other project can just check if the property is set, and if it is, use it, and not do the calculations. this actually works, the checks run only once, yay.
however this solution feels a bit hacky, as it is kind of circumventing gradle to pass along the information.
the question is, are there some alternatives that are better for this use case? we are currently using 8.11.1 - is this solution still going to be viable in later releases?Caleb Cushing
11/28/2025, 10:48 PMcatalog {...]
for publishing one?
catalog {
// declare the aliases, bundles and versions in this block
versionCatalog {
library("my-lib", "com.mycompany:mylib:1.2")
}
}
but then says we "The catalog must be created programmatically, see Programming catalogs for details."
which uses the format
dependencyResolutionManagement {
versionCatalogs {
create("libs") {
version("groovy", "3.0.5")
version("checkstyle", "8.37")
library("groovy-core", "org.codehaus.groovy", "groovy").versionRef("groovy")
library("groovy-json", "org.codehaus.groovy", "groovy-json").versionRef("groovy")
library("groovy-nio", "org.codehaus.groovy", "groovy-nio").versionRef("groovy")
library("commons-lang3", "org.apache.commons", "commons-lang3").version {
strictly("[3.8, 4.0[")
prefer("3.9")
}
}
}
}yjxf vf
11/29/2025, 9:18 AMyjxf vf
11/29/2025, 9:30 AMruns{
"named"{
propA= false
}
}yjxf vf
11/29/2025, 9:31 AMCaleb Cushing
11/29/2025, 6:57 PMlibs.versions.toml
foo = ...
foo-bar = ...
and then
dependencies {
implementation(libs.foo)
implementation(libs.foo.bar)
started working, does anyone know when? because I recall that foo wouldn't work because it wasn't the "end provider" so to speak.Martmists
11/30/2025, 4:27 PM[ASSIGNMENT_TYPE_MISMATCH] Assignment type mismatch: actual type is 'String', but 'Property<String>' was expected. Is prop.set the only way to do this in current gradle versions?Martmists
11/30/2025, 6:20 PMval outputJar by configurations.creating {
isCanBeConsumed = false
}
dependencies {
outputJar(project(":mmorpg-mod", outputJar.name))
}
tasks {
val deploy by registering(SshDeployTask::class) {
host = prop("sshDeployHost")
port = prop("sshDeployPort").toInt()
user = prop("sshDeployUser")
if (localProps.hasProperty("sshDeployPass")) {
password = prop("sshDeployPass")
}
remoteDir = prop("sshDeployPath")
from(outputJar)
}
}
mmorpg-mod subproject:
val outputJar by configurations.creating {
isCanBeResolved = true
isCanBeConsumed = true
}
artifacts {
add(outputJar.name, tasks.named("remapJar"))
}
Error:
Could not determine the dependencies of task ':deploy'.
> Could not resolve all dependencies for configuration ':outputJar'.
> Could not resolve project :mmorpg-mod.
Required by:
root project 'mmorpg-mod'
> A dependency was declared on configuration ':mmorpg-mod:outputJar' of 'root project :' but no variant with that configuration name exists.Maxim Cournoyer
12/02/2025, 8:19 AMJonas Konrad
12/03/2025, 8:35 AM% ./gradlew run
> Task :compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
> Could not resolve org.lz4:lz4-java:1.8.1.
Required by:
root project :
> Module 'org.lz4:lz4-java' has been rejected:
Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by [at.yawk.lz4:lz4-java:1.8.1(apiElements)]
> Could not resolve at.yawk.lz4:lz4-java:1.8.1.
Required by:
root project : > org.lz4:lz4-java:1.8.1
> Module 'at.yawk.lz4:lz4-java' has been rejected:
Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by [org.lz4:lz4-java:1.8.1(compile)]
poc: https://github.com/yawkat/test-case-gradle-rename-capability
is this a bug or is the metadata not supposed to be used this way?SettingDust
12/03/2025, 10:44 AMMETA-INF/versions/24/ in the dependency jar embed.
I'm embedding it with a custom configuration
val embedBoot by configurations.register(lowerCamelCaseGradleName(featureName, "embedBoot")) {
isTransitive = false
attributes
.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, ArtifactTypeDefinition.JAR_TYPE)
.attribute(REMAPPED_ATTRIBUTE, false)
.attribute(INCLUDE_TRANSFORMED_OUTPUT_ATTRIBUTE, true)
.attribute(IncludeTransformationStateAttribute.ATTRIBUTE, IncludeTransformationStateAttribute.None)
}
project.dependencies {
embedBoot(catalog.reflect)
embedBoot(catalog.classTransform)
embedBoot(catalog.classTransform.additionalClassProvider)
embedBoot(catalog.bytebuddy.agent)
}
tasks {
named(generateModsTomlTaskName) {
enabled = false
}
named<Jar>(jarTaskName) {
from(embedBoot) {
into("libs/boot")
}
}
}Kanstantsin Shautsou
12/03/2025, 12:08 PMMiles Peele
12/03/2025, 6:21 PM.kt files in a buildSrc/ -type location, exposed to consuming builds) are preferred over binary plugins (defined as .gradle files in that same consuming build) for performance reasons, but I'm not able to find those references in those docs now - does my memory serve me correctly here?