Instructions on configuring mockito as agent lacks a Gradle Groovy DSL example (currently only Kotlin DSL)

[EugenMayer]

Setup

• mockito: 5.14.2
• gradle: 8.11.1
• java: 21
• linux

Followed the instructions on https://javadoc.io/static/org.mockito/mockito-core/5.14.2/org/mockito/Mockito.html#0.3

my catalog (amongs other things)

[versions]
mockito = "5.14.2"

[libraries]
mockito-core = { module = "org.mockito:mockito-core", version.ref = "mockito"}

var mockitoAgent = configurations.create("mockitoAgent")

dependencies {
    // java agent based mockito configuration see https://github.com/mockito/mockito/pull/3454
    mockitoAgent(javaDeps.mockito.core) { isTransitive = false }
}

Issue

Running gradle, i get the error for the line mockitoAgent(javaDeps.mockito.core) { isTransitive = false }

Could not find method call() for arguments [map(valueof(DependencyValueSource)), common_dependencies_tests_e6abh55rycnig0zejb3yxvkrs$_run_closure1$_closure3@d78cf57] on configuration ':core:mockitoAgent' of type org.gradle.api.internal.artifacts.configurations.DefaultUnlockedConfiguration.

What i tried

I also tried

mockitoAgent("org.mockito:mockito-core:5.14.2") {
        isTransitive = false
}

Assumption

Is it a gradle version incompatibility (gradle 8.11.1) or something else? I'am using groovy

[bric3]

The documented instructions work fine with Gradle 8.11.1 when using kotlin dsl (which is the default in gradle init now, and the preferred way nowadays).

The call here seems to suggest a groovy DSL gradle script.

Could not find method call() for arguments [map(valueof(DependencyValueSource)), common_dependencies_tests_e6abh55rycnig0zejb3yxvkrs$_run_closure1$_closure3@d78cf57] on configuration ':core:mockitoAgent' of type org.gradle.api.internal.artifacts.configurations.DefaultUnlockedConfiguration.

Also your snipped shows javaDeps.mockito.core shouldn't it be libs.javaDeps.mockito.core ?
I'm away from keyboard at the moment. But I would suggest to adapt the documentation example to the build.gradle if that's your case. Or eventually convert your script to kotlin dsl.

 val mockitoAgent = configurations.create("mockitoAgent")
 dependencies {
     testImplementation(libs.mockito)
     mockitoAgent(libs.mockito) { isTransitive = false }
 }
 tasks {
     test {
         jvmArgs("-javaagent:${mockitoAgent.asPath}")
     }
 }

[EugenMayer]

Also your snipped shows javaDeps.mockito.core shouldn't it be libs.javaDeps.mockito.core ?

This depends how you define your catalog

dependencyResolutionManagement {
    versionCatalogs {
        create("springDeps") {
            from("...")
        }
        create("javaDeps") {
            from("...")
        }
    }
}

Becomes esp important if you use more then one catalog.

The documented instructions work fine with Gradle 8.11.1 when using kotlin dsl (which is the default in gradle init now, and the preferred way nowadays).

I know, but since kts syntax is by far not in feature parity with groovy ( most importantly the apply from: limitations due to strong typing ), which makes splitting up build gradle files very hard (without starting the huge effort of convention plugins) - so not everyone yet is keen to use it. (i love kotlin, but here, it is not just a straight win)

Or eventually convert your script to kotlin dsl.

Is there a way to go the other way around? What would be the counter part in groovy?

Thanks for the help

[bric3]

Is there a way to go the other way around? What would be the counter part in groovy?

Here's how the same example can be done in groovy, note I'm still using the default catalog "libs" here.

configurations {
    mockitoAgent
}
dependencies {
    mockitoAgent(libs.mockito) {
        transitive = false
    }
}
tasks {
    test {
        jvmArgs += "-javaagent:${configurations.mockitoAgent.asPath}"
    }
}

---

Out of scope for this issue.

On the kotlin dsl side, you mentioned the limitations of apply from: due to strong typing. COuld you be more explicit, I never encountered problems for apply from in particular. I indeed had to write things differently in kts by using names explicitly like named / getByName but that's what the Groovy Dsl does under the hood anyway and not specific to split files ; personally I actually find it safer because it's more explicit.

[EugenMayer]

This works, thank you! Maybe we should add the non kts example to the docs?

apply from: due to strong typing. Could you be more explicit,

When we build our multi-project / composition project with gradle, we do split our configuration into different pieces, so we

• can share configuration templates between projects
• the build.gradle does not look like a 1000 lines mess

e.g.

// common
apply from: "$rootProject.projectDir/../gradle/common_compile.gradle"
apply from: "$rootProject.projectDir/../gradle/common_kotlin.gradle"
apply from: "$rootProject.projectDir/../gradle/common_repositories.gradle"
apply from: "$rootProject.projectDir/../gradle/common_dependencies.gradle"
apply from: "$rootProject.projectDir/../gradle/common_publish.gradle"
apply from: "$rootProject.projectDir/../gradle/common_tasks.gradle"
apply from: "$rootProject.projectDir/../gradle/common_dependency_check.gradle"
apply from: "$rootProject.projectDir/../gradle/common_dependencies_tests.gradle"
apply from: "$rootProject.projectDir/../gradle/common_tests_config.gradle"

// project specific
apply from: "$rootProject.projectDir/gradle/compile.gradle"
apply from: "$rootProject.projectDir/gradle/sonarqube.gradle"
apply from: "$rootProject.projectDir/gradle/publish.gradle"
apply from: "$rootProject.projectDir/gradle/dependencies.gradle"

When you do this with kts gradle, most or all of them will not work, since e.g. sonarqube.gradle will need to resolve the sonarqube option

sonarqube {
    properties {
       ....
    }
}

Which a simple "include" at an arbitrary position the kts compiler cannot guarantee - thus such things cannot compile.

For this to solve with kts based gradle, one will use company wide gradle-convention-plugins for the "common" stuff and the project wide convention plugins for the project. This is an effort, sure i is the better option in general - but it is nice to not being forced to go with the big guns.

Again, you do no need to sell kotlin to me, we are basically only doing kotlin here, but for the gradle part, while i love the strong-typing, it comes with the named limitations which are a heavy price to pay (for us).

[bric3]

Maybe we should add the non kts example to the docs?

Yes I will. Meanwhile I will rename this issue, so it will be easier to find.

---

I see your point. I lived with it in the past. But now I think it's worth to invest in Kotlin DSL plugins. Maybe something like this https://github.com/melix/includegit-gradle-plugin from @melix could work for you ?