Kotlin-dsl-samples: Subprojects setup issue

[soberich]

kts.zip

Expected Behavior

Current Behavior

Basically I did not even managed to set up an susseccfully build not a single descent java project
applying certain needed plugings simply crushes the build (exactely applying in two projects => root project and its subproject. In the listing provided IF to comment out the dependencyManagment section than it crashes with NPE. The same behavior with buildScan plugin. If i apply it in root project and put the buildScan config closure in same root gradle.build.kts in whether allprojects or subprojects section it builds ok. But if I ALSO apply buildScan plugin in user-service submodule than NOT ONLY I can the buildScan closure not resolved by IDEA, but also the build fails (even to delete the buildScan clousure in submodule and just leave the plugin applied in plugins {}
If try all that completele replacing plpugins {} notation with buildScript {} notation then the half of bith scripts turn red and it's a bigger trouble.
BTW setting.gradle.kts is not supported syntax. it builds with both rootProject.name .. and include(":...") turned in red competly. I spend several hours wot understand that it is just not highlighted correct.
Cache cleaned many many times etc. All common solutions did not succeeded
BTW 2 IdeaModule and the whole idea plugin SUDDENLY started to raise error and failed the build with no changes from my side. After like a dozen successful builds . boom and it is just kind of not resolved.
But these last two are minors
biz.aQute.bnd plugin as well crashes the build if present in bith root and sub- projects

Context

Steps to Reproduce (for bugs)

gradlew -stacktrace build
coment out dependenciesManagment in current listing and it builds ok

Your Environment

build fules attached

• Build scan URL: https://scans.gradle.com/s/cm2hewegemdvo https://scans.gradle.com/s/clx6e4234xkra
  gradle 4.4.1
  gradle 4.5-rc1
  IDEA 2017.3.2
  JDK 1.8_152
  JDK 9.0.1_11
  kts.zip

[gildor]

You getting crash because of trying to configure dependency-management plugin on project where this plugin is not available. You applied it only to root project.

Add plugins.apply("io.spring.dependency-management") to allprojects block

But kotlin-dsl should throw a proper exception in this case instead of NPE of course. @bamboo Not sure, should I create a separate issue about this or track it here

[gildor]

Same for all other plugins. You apply plugin only to root project, but then trying to use them in subprojects.
Kotlin-DSL tries to provide type-safe accessors to extension methods.
It actually solves part of the problem and does not allow you to use non-available plugins in a project (generate acessors only for projects where this plugin available).
But cannot prevent you to use them in a context where they actually have a different meaning (like allprojects, subprojects). Not sure that there is any valid way to solve this. But good error handling should be enough.

[soberich]

yes, thank you.
I figured that out. I wonder now, WHY would anyone (except spring-boot project probably) use the dependency-managment plugin at all? To double declare all the deps )) everywhere ??
Ok, so the question remain about to externalize some configuraion part.
Let's say I want to declare the dependencyManagment closure (or if to keep that simple, any other) in the external file. Just like
build.gradle.kts

...
apply(from("deps.gradle.kts"))
...

deps.gradle.kts

dependencyManagement {
        dependencies {
            dependency("org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlinVersion")
            dependencySet("org.osgi:$osgiVersion") {
                entry("osgi.core")
                entry("osgi.cmpn")
            }
            dependency("org.osgi:org.osgi.annotation.versioning:$osgiAnnotationVersioningVersion")// 1.0.0
            dependency("org.apache.aries.blueprint:org.apache.aries.blueprint.cm:$ariesCmBlueprintXmlnsVersion")// 1.1.0
            ...

            /*Testing*/
            dependencySet("org.junit.vintage:$junitVersion") {
                entry("junit-vintage-engine")
            }
        }
    }

even if I apply in deps.gradle.kts

plugins {
    java
    id("io.spring.dependency-management") //version "1.0.4.RELEASE"
}

with version or not like it is now (commented out)
the dependencyManagement section is completely in red

aaand the settings.gradle.kts is completely on red - but this is IntelliJ problem, I understand.
What about externalzing some blocks ?

[gildor]

I've created an issue about settings.gradle.kts syntax highlighting (not sure that this is the same as your, because highlighting works for me, but only partially). I have this problem too.
https://github.com/gradle/kotlin-dsl/issues/658

[gildor]

I wonder now, WHY would anyone (except spring-boot project probably) use the dependency-managment plugin at all? To double declare all the deps

I don't understand you. You can use allprojects block, you just should also apply plugin to each project. Plugins applied in plugins dsl applying only to current project but also available in build classpath for other projects.
Or are you talking about dependency-managment plugin itself? I don't know. Not familiar with Spring and this plugin

Script plugins for now not allow you to use static accessors
https://github.com/gradle/kotlin-dsl/issues/432

You still can use allprojects or subprojects block tho

[soberich]

Ok, thank you for pointing to static accessors.
Sorry, but about the

I don't understand you. You can use allprojects block, you just should also apply plugin to each project. Plugins applied in plugins dsl applying only to current project but also available in build classpath for other projects.

then we have the issue with the plugin or I still did not understand the right syntax.
Please clarify...
If you will look at the zip I originally posted with all files, you may see that dependencyManagement is IN THE allprojects { ... }
which , if I understood the very last your massage should lead to the fact that dependencyManagement is LIKE inside the module_build.gradle.kts which ALSO always HAD id("io.spring.dependency-management") applied to it..
So, I don't understand why is it NPE.
Everything exactly that like it should be..

[gildor]

See, you can use dependencyManagement in this block. just because your root project contains this plugin (you add dependency on in and applied it in plugins{}). But at runtime, during configuration of your other projects Gradle will try to access extension of dependencyManagement and will crash with NPE, because static accessor doesn't expect that this plugin is not available in this project.
So, you should also apply dependencyManagement plugin to all your projects (not only to the root) before using this extension:

allprojects {
   // Plugin already in build classpath, you add it in `plugins{}` block, now just apply it
   plugins.apply("io.spring.dependency-management")
   dependencyManagement {
      ...
   }
}

You will get the same error with Gradle Groovy, because Gradle cannot find dependencyManagement extension in this case. Same with Kotlin-DSL, but unfortunately it throws NPE instead of something like "extension "dependencyManagement" not found in project :MyProject". Also, actually it means that Kotlin-DSL would have more pleasant error message than Gradle with Groovy, because actually knows that you trying to use an extension. Groovy will just complain that dependencyManagement not found

[eskatos]

Closing as answered.