https://kotlinlang.org logo
Title
s

spierce7

12/09/2019, 7:41 PM
If I have a Kotlin gradle script file that I want to apply to a project
./gradle/deps.gradle.kts
, do I have a way of statically accessing the file’s classes it defines externally in another kotlin file where I do something like this:
plugins {
  `kotlin-dsl`
}

buildscript {
  apply {
    file(File(project.rootDir, "gradle/deps.gradle.kts"))
  }

  dependencies {
    classpath(Plugins.kotlin) // Unresolved reference error
  }
}
o

octylFractal

12/09/2019, 7:42 PM
I don't think so, generally the recommendation is to use
buildSrc
for that
but
buildSrc
won't work for the
buildscript
block in particular, but you could instead declare that
classpath
dependency as an
api
dependency of
buildSrc
s

spierce7

12/09/2019, 7:44 PM
I had all my dependencies setup in a file inside my
buildSrc
, but now I’m trying to add some extension methods for the
multiplatform
plugin inside of
buildSrc
. The file I posted above is actually the
./buildSrc/build.gradle.kts
file. It’s important for circleci caching reasons that I have all my dependency information inside a single file, and I’m trying not to duplicate my kotlin version into 2 locations.
o

octylFractal

12/09/2019, 7:46 PM
curious as to why you're adding the kotlin plugin to the classpath there then
kotlin-dsl
already applies one version
and the plugin applied to
buildSrc
is irrelevant for the one applied to the project
s

spierce7

12/09/2019, 7:47 PM
I want to be able to access the
multiplatform
plugin classes, so that I can add some extension methods for the plugin to my
buildSrc
If you know of a better way - I’m open
o

octylFractal

12/09/2019, 7:47 PM
right, but that means it's a regular dependency of the buildSrc project, i.e. use the normal
dependencies {}
block
s

spierce7

12/09/2019, 7:47 PM
oh - good call
I still have the same problem though - don’t I?
o

octylFractal

12/09/2019, 7:48 PM
yes, but if you can manage to parse the file instead, then at least that works somewhat
iirc.
buildscript
is more strict on what can be placed inside it
s

spierce7

12/09/2019, 7:49 PM
my plan was to move my dependencies file to a file that could be applied
that doesn’t appear to work though
o

octylFractal

12/09/2019, 7:50 PM
if you add the dependencies in
deps.gradle.kts
instead, it might work
s

spierce7

12/09/2019, 7:50 PM
whats what I’m trying
I’m not getting any static resolution of the classes defined in those files when applied though
o

octylFractal

12/09/2019, 7:51 PM
right, you can't get the classes from inside
what I'm saying is to call
dependencies {}
in there
s

spierce7

12/09/2019, 7:51 PM
I’m not 100% sure - but am I required to define things on the
ext
, to gain access outside of there
o

octylFractal

12/09/2019, 7:51 PM
then you don't need the class
s

spierce7

12/09/2019, 7:51 PM
oh - I can’t do that. My team has like 50 modules
that’d get to hairy I think - assuming I’m understanding you correctly
o

octylFractal

12/09/2019, 7:51 PM
yea, probably
s

spierce7

12/09/2019, 7:52 PM
I guess my best option is to duplicate the logic, and just explicitly declare the dependency here?
o

octylFractal

12/09/2019, 7:52 PM
yea
s

spierce7

12/09/2019, 7:52 PM
😞 Oh well
o

octylFractal

12/09/2019, 7:52 PM
might be a good idea to file an issue with gradle for this sort of use-case
s

spierce7

12/09/2019, 7:52 PM
thanks for your help!
o

octylFractal

12/09/2019, 7:53 PM
it's usually only an issue with the kotlin plugin, but it is a pretty bad pain point
s

spierce7

12/09/2019, 7:53 PM
I’ll do that
actually
the entire point is moot
when applying the kotlin dependency - the entire thing keels over and gives me an exception -
> com/android/build/gradle/BaseExtension
g

gildor

12/09/2019, 11:24 PM
Kotlin is statically typed language, it will not work with dynamically applied script, because there is no way to resolve members of dynamically applied script on compilation time
You can do only something like ext["kotlin"] or properties["kotlin"]
This is an exception related on Android plugin
But overall, it's known limitation of buildSrc. Overall approach with manual application of version will work if you use dynamic syntax