<@U0B8CHT6E>: there is no way for a JVM-language G...

# build-tools

[alexey.tsvetkov]

@madisp: there is no way for a JVM-language Gradle plugin to tell Gradle that there is an additional classes directory to search when running tests or packing a jar.
Thus the only way to make Gradle aware of Kotlin classes is to put them into a Java output directory (e.g. build/classes/main).
We could output directly to a Java output directory like Groovy or Scala plugins do, however this is not convenient because:
1. When compiling incrementally we want kotlin classes to be in a classpath (because unaffected sources are not compiled). However, we don't want java classes in classpath, because Kotlin (without KAPT) is compiled before Java, so Java classes could be outdated (Kotlin compiler can parse and resolve Java sources, so it's OK to depend only on Java sources).
2. Other plugin can delete or corrupt Kotlin classes in Java output directory.
a. Java incremental compilation could delete Kotlin class after a J2K conversion. There was the following sequence: new Kotlin source compiled->Java IC detects deleted (converted) source file and deletes class with a corresponding name (that is newly compiled Kotlin class).
b. New Android plugins (2.1+) have IncrementalCompilationSafeguard (I'm not sure if it's the exact name) task that wipes out a Java output directory whenever generated files are changed (e.g. R.java, BuildConfig.java).
The current workaround for the problems described above is to compile to separate directory, then copy Kotlin classes to Java output directory after Java is compiled.
The copying is made incrementally if possible.
When there will be API to register additional classes directory in core Gradle and Android plugin, we will happily remove the copying hack 🙂