hi there - I can't clarify the behavior of `buildSrc/build.gradle.kts` - does it affects onto main `...

# gradle

[mp]

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"

[gildor]

What do you mean “affects onto main”?

[gildor]

Every dependency defined in buildSrc/build.gradle.kts will be part of your build classpath

[mp]

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

[gildor]

not override “plugins block”

[gildor]

both will be used

[napperley]

There are kts tooling issues that appear when using buildSrc, which don't normally appear when buildSrc isn't used (defined).

[mp]

My dependencyManagement block becomes unresolved after buildSrc plugins block doesn't contains spring-dependencymanager-plugin but main plugins block does

[mp]

oh so its about tooling... IC

[napperley]

In my case code completion breaks and there are elements where the text is red everywhere, even though the elements are already defined.

[gildor]

It will be probably solved if you reopen project or clear project cache

[gildor]

also you can have buildSrc errors

[mp]

I think Ivalidate+Restart doesn't very useful in this case - I`ve tried it few times

[mp]

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

[mp]

and thought that place it to the buildSrc good choice

[napperley]

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.

[gildor]

I don’t have such problemn with buildSrc

[napperley]

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.

[gildor]

Such as?

[napperley]

Publishing libraries, and Kotlin JS testing via the unofficial Gradle Node plugin.

[gildor]

publishing works for me

[mp]

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)

[gildor]

Yes, this usual reason. buildSrc is broken, so nothing cannot be resolved, because buildSrc is on lower level than your configs

[gildor]

Usually Kotlin DSL errors are pretty clear, try check logs and use --stacktrace

[mp]

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

[gildor]

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

[mp]

oh - build classpath... I miss understood your 1st message with build classpath... And thought that all from buildSrc will does to main classpath

[mp]

so thx! discussion was helpful! kts build looks very nice