After converting a build.gradle to Kotlin, I get “...

# gradle

[eekboom]

After converting a build.gradle to Kotlin, I get “Unresolved reference: compile”. How do you set common dependencies from the parent project?

[Thiago Nerys]

try implementation instead of compile

[eekboom]

No, same error. (But of course, good advice in general to use “implementation” rather than “compile”.)

[Thiago Nerys]

guess it's gradle version

[eekboom]

Woah. Very interesting. I am on latest 6.0.1

[eekboom]

The only way I am able to make it work is by adding this in front of it val compile by configurations

[eekboom]

Hm, is your root project also using the “java” plugin?

[Thiago Nerys]

Root project.

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
   kotlin("jvm") version Versions.kotlin
   id("org.springframework.boot") version Versions.spring
   id("org.jetbrains.kotlin.plugin.spring") version Versions.kotlin
   id("io.spring.dependency-management") version Versions.springDependencyManagement
}

allprojects {
   repositories {
      mavenCentral()
   }

   tasks {
      withType(KotlinCompile::class).all {
         kotlinOptions {
            jvmTarget = "11"
            freeCompilerArgs = listOf("-Xjsr305=strict")
         }
      }
   }
}

subprojects {
   plugins.withType<JavaPlugin> {
      dependencies {
         compile("org.slf4j:sllf4j-api")
         implementation("org.slf4j:sllf4j-api")
      }
   }
}

dependencies {
   implementation(project(":integration"))
   runtime(project(":implementation"))

   implementation(kotlin("stdlib-jdk8", version = Versions.kotlin))
   implementation(kotlin("reflect", version = Versions.kotlin))

   implementation("org.springframework.boot:spring-boot-starter-web") {
      /* Excluding Tomcat dependency */
      exclude(module = "spring-boot-starter-tomcat")
   }
   implementation("org.springframework.boot:spring-boot-starter-undertow")
}

[eekboom]

So your root project has `kotlin("jvm") version Versions.kotlin`and I think that’s why it works for you. If I add plugins { id("java") … it also works for me.

[eekboom]

Which is very strange, because it really does add the dependencies to the subprojects (they can use classes from the dependency just fine).

[Thiago Nerys]

Can you declare the java plugin in the root project with apply false?

[eekboom]

gradle won’t let me do that:

Error resolving plugin [id: ‘java’, apply: false]
> Plugin ‘java’ is a core Gradle plugin, which is already on the classpath. Requesting it with the ‘apply false’ option is a no-op.

[eskatos]

If the root project has no configuration named compile then there’s no static accessor in its build script. This is expected, see <https://docs.gradle.org/current/userguide/kotlin_dsl.html#type-safe-accessors>

In that case you should use string references instead:

subprojects {
  plugins.withType<JavaPlugin> {
      dependencies {
         "compile"("org.slf4j:sllf4j-api")
         "implementation"("org.slf4j:sllf4j-api")
      }
   }
}

Note the double quotes.

[eekboom]

Thanks for the answer! What really confuses me: Why does it actually work when the root project has a “compile” configuration? After all it needs to add the dependency to the sub project’s “compile” configuration. However, it really works at runtime. So what am I missing?

[eekboom]

And isn’t there a way to make gradle aware of the actual subprojects’ configurations? There is already a `withType<JavaPlugin>`around it - but that does not help. Neither does `configure<JavaPluginConvention> {`help 😞

[eskatos]

The type-safe accessors are generated for model elements that exist after applying the plugins {} block. That’s why withType<JavaPlugin> {} or configure<JavaPluginConvention> {} won’t help.

Those accessors are Kotlin extension functions, in that case on the DependencyHandler type. They are static. That’s why they are usable on the DependencyHandler of sub projects in a subprojects {} block.

Tradeoffs 🤷‍♂️

[eekboom]

Thanks!

[eskatos]

https://kotlinlang.slack.com/archives/C19FD9681/p1575981846362800?thread_ts=1575981076.361500&amp;cid=C19FD9681

[eskatos]

This is also a nice way to do it. It basically does the same, refer to the configuration by name.

[eekboom]

Yeah, I think it is a little nice, even though it really is a glorified string based access, right.

[eekboom]

What I still don’t understand is why it works if the root project itself has the Java plugin. Why don’t the dependencies get added to the root project’s configuration only?

[eskatos]

Because the Kotlin extension is static. In other words it applies to a type, not an instance.

[eekboom]

Oh yeah, of course! Thanks again!

[eskatos]

So,

dependencies {
    compile("foo:foo:1.0.")
}
subprojects {
    dependencies {
        compile("foo:foo:1.0.")
    }
}

it’s the same Kotlin function fun DependencyHandler.compile(dep: String) (simplified version)
but applied to different DependencyHandler instances. In the first case to the root project, in the second case to each subprojects.