The class is used on both server and client, but it was defined in
server module.
Gradle plugin worked, because all classes are present in kotlin compiler
embeddable, but the code was red in IDE (which is correct because
Gradle plugin does not depend on daemon server module).
Each Kotlin task now writes build history to separate file.
A map of output directories to history files is used to get changes for
modified files.
#KT-22623 fixed
Use distJar configuration instead.
It's necessary because currently when using default-type, subproject
starts having a transitive dependency to :kotlin-stdlib-common
and that leads to exception from KT-20897 when building light classes
This change might be reverted once KT-23942 is fixed
#KT-23942 Submitted
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
In some cases IC needs to perform a rebuild.
Before this change IC was not clearing output directories
besides destination dir for classes, so for example
kapt stubs were not cleared.
Stalled stubs might lead to compile errors.
For example:
1. foo/XGen.java is generated from annotated class foo/X (XGen also
references X).
2. foo/X is moved to bar/X and some other change forces IC to rebuild.
3. kapt generates bar/X stub, but foo/X stub
was not removed because stubs dir is not cleared.
4. kapt runs annotation processors, foo/XGen.java is generated from
foo/X stub, bar/XGen.java is generated from bar/X stub.
5. kotlinc rebuilds. Since destination dir is cleared properly,
only bar/X.class exists.
6. javac tries to compile foo/XGen and fails, because it
compiles against actual Kotlin classes, not stubs.
This commit fixes the issue by passing all output directories
of a task from Gradle to Kotlin IC.
#KT-21735 fixed
The RMI documentation (http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/javarmiproperties.html)
says it is useful to set up a `java.rmi.server.hostname`
system property on a client and a server.
When the property is set up on a client, I saw that "RenewClean" threads
stopped listening to my external IP, so all client and server threads
are now only listening the loopback interface.
I also changed the way the property is set up on the server side:
before the change it was passed in jvmargs at a process launcher.
I moved this code directly to the main method of the daemon,
because it is easy to forget to set up the property,
when running the main for debug purposes.
Alexey Tsvetkov