https://kotlinlang.org
Join Slack
After converting a build.gradle to Kotlin, I get “Unresolved reference: compile”. How do you set com...
# gradle
e
After converting a build.gradle to Kotlin, I get “Unresolved reference: compile”. How do you set common dependencies from the parent project?
t
try 
implementation
instead of 
compile
e
No, same error. (But of course, good advice in general to use “implementation” rather than “compile”.)
t
guess it's gradle version
e
Woah. Very interesting. I am on latest 6.0.1
The only way I am able to make it work is by adding this in front of it 
val compile by configurations
Hm, is your root project also using the “java” plugin?
t
Root project.
Copy code
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")
}
e
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.
Which is very strange, because it really does add the dependencies to the subprojects (they can use classes from the dependency just fine).
t
Can you declare the java plugin in the root project with apply false?
e
gradle won’t let me do that:
Copy code
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.
e
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:
Copy code
subprojects {
  plugins.withType<JavaPlugin> {
      dependencies {
         "compile"("org.slf4j:sllf4j-api")
         "implementation"("org.slf4j:sllf4j-api")
      }
   }
}
Note the double quotes.
e
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?
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 😞
e
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 🤷‍♂️
e
Thanks!
e
This is also a nice way to do it. It basically does the same, refer to the configuration by name.
e
Yeah, I think it is a little nice, even though it really is a glorified string based access, right.
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?
e
Because the Kotlin extension is static. In other words it applies to a type, not an instance.
e
Oh yeah, of course! Thanks again!
👍 1
e
So,
Copy code
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.
113 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by