This message was deleted.
# community-support
s
This message was deleted.
plus1 2
e
they aren't independent classloaders though? I can put a
Copy code
buildscript {
    dependencies {
        classpath(platform("com.pinterest.ktlint:ktlint-bom:1.1.1"))
    }
}
plugins {
    id("org.jmailen.kotlinter") version "4.1.1"
}
and see that the plugin's dependencies are upgraded from ktlint:1.0.1 to ktlint:1.1.1, for example
➕ 1
t
hmm maybe I'm just tired, but I could have sworn there was some weirdness there. Happy to simply be wrong on that point though
j
AFAIK adding a plugin to the plugins block is just shorthand for adding the plugin’s marker dependency to the class path configuration
🤔 1
a
There's definitely only one ClassLoader created per project, and both
plugins { }
and their dependencies and dependencies added via
buildscript { }
end up there (which also has its problems, but that's another topic)
Do you have some examples of problems 2) and 3)?
t
didn't gradle used to have a class or interface named something like
HasMultipleClassLoader
or something? I have vague recollections from several years ago for 2 and 3, I mean the plugins block doesn't support syntax to add arbitrary dependencies or arbitrary dependency constraints. For example
Copy code
buildscript {
  dependencies {
    classpath("...") // for example
    constraints { ... } // for example
  }
}

plugins {
  id("...") // this is all I can do
}
I am a fan of simplicity in build scripts, and so I try to eliminate
buildscript {}
blocks and have only a
plugins {}
block for build dependencies
a
I meant, do you have some examples of where you'd like use arbitrary dependencies or constraints with build scripts?
t
Copy code
buildscript {
  dependencies {
    classpath(platform(libs.kotlinGradleBom))
  }
}
here we apply a platform/BOM to our buildscript classpath
or here
Copy code
dependencies {
    // This dependency resolves an issue that blocked AGP 7.1 usage. See dependencies.gradle.
    classpath platform(deps.grpc_bom)
    classpath enforcedPlatform(deps.kotlin.bom)

    // Latest version of intellij-gradle plugin tries to push to newest Kotlin, so watch out!
    classpath(deps.intellij) {
      exclude group: 'org.jetbrains.kotlin'
    }

    classpath(deps.wire.gradle_plugin) {
      // Wire 4.6.x leaks Kotlin 1.8.20
      exclude group: 'org.jetbrains.kotlin'
    }

    constraints {
      // Some plugins (e.g., Paparazzi) try to quietly upgrade the version of AGP and its dependencies that we use.
      // Will eventually be fixed by <https://github.com/cashapp/paparazzi/pull/648>
      classpath('com.android.tools.build:gradle') {
        version {
          strictly agpVersion
        }
      }
that is a snippet from a real project
I've seen other examples where dependencies provide service loaders which, if present on the classpath, are used at (build) runtime