This message was deleted.
# android
s
This message was deleted.
e
if you have multiple subprojects that are using the kotlin plugin, and it's not in the root project's classpath, it'll get loaded multiple times and can lead to issues
☝️ 1
c
Okay. So if i already have kotlin in the root project then it should be safe to delete (if im understanding you right)
by "kotlin in the root project" I mean this
Copy code
dependencies {
  classpath(kotlin("gradle-plugin", version = "1.7.0"))
m
Most likely yes (both
classpath
and
plugins {}
are in the root
build.gradle.kts
, right?)
👍 1
If you have other plugins, I'd recommend you load them all next to your
classpath(kotlin("gradle-plugin", version = "1.7.0")
so that conflict resolution happens correctly
c
I have a feeling the auto AGP updater added this line. I have no idea how else it would've been added. Maybe @Xavier Ducrohet knows if AGP updater would do something like that. @Martin in regards to your second comment. I'm not sure what that means. How do I "load them all..."
m
Load them all using the root
classpath()
. For an example, one of your sample script in the other message has this:
Copy code
plugins {
  id("com.github.ben-manes.versions") version "0.42.0"
}
If
com.github.ben-manes.versions
has transitive dependencies that conflict with AGP, they might get loaded separately and crash at runtime
🤔 1
c
Forgive my ignorance. "Load them all using the root
classpath()"
how would I do that?
m
classpath()
adds the plugin jars to the classpath. This is what I mean by "loading"
"applying" is when you do
Copy code
plugins {
  id("com.example")
  // or equivalent
  id("com.example").apply(true)
}
c
Oh. So you reccomend "loading" via classpath instead of applying via plugins{}? 🤔
Let me read through this thread again to make sure I'm not missing something basic here. 😅 Sorry for being a noob here
m
Mostly, I recommend you do everything in a single place for transitive resolution to happen consistently
No worries, this stuff is hard ™️
Also, this blog post is excellent: https://dev.to/autonomousapps/a-crash-course-in-classpaths-build-l08 for some details about classpath
c
Tony FTW
💯 2
I guess I'm intergued and blown away that I haven't hit an issue with this stuff before and why I'm just learning about it now. lol
m
Plugin authors might hide this issue from you by shadowing extensively the transitive dependencies
🙃 1
c
Maybe this ends up being the solution to my second issue below. 🤷‍♂️
m
Maybe although that second issue looks more IDE related ?
c
It does seem IDE related. Just driving me insane.
because the 3 projects are pretty much identical
e
I have a feeling the auto AGP updater added this line. I have no idea how else it would've been added
Can't speak for this particular case, but AS has added code to my root gradle build file related to Kotlin before. Usually without me realizing it, which leads to lots of head scratching.
n
plugins is the recommended way. like you have here: https://gradle-community.slack.com/archives/CJYS1DAP5/p1657579112700169
m
What's the difference between
Copy code
plugins {
  id("org.jetbrains.kotlin.jvm") version "1.7.0" apply false
}
And
Copy code
buildscript {
  dependencies {
    classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.0")
  }
}
I understand the
plugins {}
block can generate type-safe accessors but that's only if you apply the plugin, right?
n
From @Paul Merlin
The result is basically the same but using
plugins { ... apply false }
should be preferred for consistency, brevity, and readability
m
Yea well, there are tradeoffs... Like if I have a multi-module Android build, it's weird to favour
com.android.library
over
com.android.application
(or the other way around)
At least using maven GAV like
com.android.tools.build:gradle:7.4.0-alpha08
make it explicit that it's only about "loading"
p
True. A
-base
plugin is a good fit in those cases, if available.
👍 2
n
cc @Adam and @Boris Farber since we were also discussing this at Droidcon.
🙌 2
🇩🇪 1