Hi again,
Hmm, that's interesting. You seem to use
$buildDir in the kotlin.srcDir specifier as well - what happens if you remove this, does it break similarly?
YMMV, but we opted for an approach where we put the generated code in a source set of its own, like this (Groovy code but I'm sure you can convert it to Kotlin if needed):
sourceSets {
generated {
java
// Adds the production classes from the main source set to the compilation and runtime
// classpaths of the `generated` source set.
compileClasspath += sourceSets.main.output
runtimeClasspath += sourceSets.main.output
}
}
We then consume it like this from another project (we use a multi-project Gradle build):
dependencies {
implementationModuleBundle project( ':centre-audit-db-schema' )
implementationModuleBundle project( path: ':centre-audit-db-schema', configuration: 'generated' )
// ...
}
You are of course free to do it however way you wish, but I think the main advantages for us with this approach are:
- Makes it easier to exempt generated code from Checkstyle and/or Spotbugs
- Makes it much easier to avoid "circular dependencies" between your main source set and the generated code
As for your original problem: what directory does it use when do not specify withBasedir? Or does it (the generate files) go somewhere where you can't even find them?
🙂 I think the current working directory should be
$projectDir by default (i.e. the project root), so if you want the files under
$buildDir you probably have to specify
build/generated/kotlin instead of just
generated/kotlin.
If you decide to go with a separate "generated" source set as in my example above, that directory would be "src/generated/java"
instead (or in your case, "src/generated/kotlin").
I don't know if these suggestions make it better or worse for you, but hopefully it can serve as an inspiration for you and others who are (like us) struggling with getting the code generation working properly with
Gradle. It was clearly quite a bit of work before I got this working properly in our project. Gradle can really be a beast sometimes: it's great when you have it working, and extremely flexible because of its DSL and multi-pass-oriented approach (parsing the
Gradle build scripts vs running the parsed tasks). But with great flexibility comes great complexity...
Best regards,
Per