https://kotlinlang.org logo
Title
m

mp

09/06/2018, 8:42 AM
hi there - I can't clarify the behavior of
buildSrc/build.gradle.kts
- does it affects onto main
build.gradle.kts
? because when I add
buildSrc/build.gradle.kts
and try to define some dependencies for my plugin - main file becomes "red"
g

gildor

09/06/2018, 8:43 AM
What do you mean “affects onto main”?
Every dependency defined in buildSrc/build.gradle.kts will be part of your build classpath
m

mp

09/06/2018, 8:45 AM
for example looks like
buildSrc
plugins block override main file plugins block... not add new plugins but remove old and add plugins from
buildSrc
as is
g

gildor

09/06/2018, 8:47 AM
not override “plugins block”
both will be used
n

napperley

09/06/2018, 8:51 AM
There are kts tooling issues that appear when using buildSrc, which don't normally appear when buildSrc isn't used (defined).
m

mp

09/06/2018, 8:52 AM
My
dependencyManagement
block becomes unresolved after
buildSrc
plugins block doesn't contains
spring-dependencymanager-plugin
but main plugins block does
oh so its about tooling... IC
:yes: 1
n

napperley

09/06/2018, 8:54 AM
In my case code completion breaks and there are elements where the text is red everywhere, even though the elements are already defined.
g

gildor

09/06/2018, 8:55 AM
It will be probably solved if you reopen project or clear project cache
also you can have buildSrc errors
:yes: 1
m

mp

09/06/2018, 8:56 AM
I think Ivalidate+Restart doesn't very useful in this case - I`ve tried it few times
so will w8 updates - was pretty exited with move gradle.build to kts... but have need to move one of custom maven plugins inside gradle project
and thought that place it to the buildSrc good choice
n

napperley

09/06/2018, 8:58 AM
From what I understand the problem has to be fixed on both sides. The IntelliJ Kotlin plugin has a fix, but the Gradle Kotlin plugin doesn't so it will have to catch up with the IntelliJ plugin.
g

gildor

09/06/2018, 9:01 AM
I don’t have such problemn with buildSrc
n

napperley

09/06/2018, 9:02 AM
Delegating some of the build logic to a separate build.gradle file is an option even though it isn't a ideal solution. That solution has helped to solve some very difficult issues, where the only other option was to completely switch to the Groovy DSL.
g

gildor

09/06/2018, 9:02 AM
Such as?
n

napperley

09/06/2018, 9:03 AM
Publishing libraries, and Kotlin JS testing via the unofficial Gradle Node plugin.
g

gildor

09/06/2018, 9:12 AM
publishing works for me
1
m

mp

09/06/2018, 9:19 AM
Andrey was right! I`ve broken buildSrc/gralde.build.kts but I can't define mistake exactly (maybe was need clean build with valid content)
g

gildor

09/06/2018, 9:21 AM
Yes, this usual reason. buildSrc is broken, so nothing cannot be resolved, because buildSrc is on lower level than your configs
Usually Kotlin DSL errors are pretty clear, try check logs and use --stacktrace
m

mp

09/06/2018, 9:23 AM
One more additional question - why buildSrc`s build file have such affect onto final runtime?! It seems a bit unexpected for me. In case with my wish to put plugin in buildSrc that will start before tests and stops after
g

gildor

09/06/2018, 9:27 AM
I didn’t get your question. use case of buildSrc is to write some plugins, tasks or just functions, all this code become part of your build classpath and can be used by any build.gradle of your project So because buildSrc is part of build logic it runs before any other project
👍 1
m

mp

09/06/2018, 9:28 AM
oh - build classpath... I miss understood your 1st message with
build classpath
... And thought that all from buildSrc will does to main classpath
so thx! discussion was helpful! kts build looks very nice