Before the change consecutive incremental builds with different project versions
produced kotlin-gradle-plugin with the same project.version in project.properties file
1) Exclude the providers arguments from the kapt inputs, as the values
may contain absolute paths, may be output properties etc. The providers
should correctly annotate their inputs.
2) Fix the options passed to kapt as 'value=option' (leading to all the
options collapse into one with the null key), use 'key=option' instead
to make Kapt pass them as '-Aoption'.
Issue #KT-23866 Fixed
Issue #KT-25027 Fixed
Jar's inputs can contain zipTrees in case of fat jars,
which can cause slow build
(Gradle unpacks them into temporary dir; that can be slow)
#KT-24956 fixed
Since the property is public, it can be invoked from outside,
possibly trough other properties.
This can lead to unwanted side effects: we can create taskBuildDirectory,
because some other task reads the property in parallel with 'clean' task
in current project.
That's exactly what happened when we referenced the property from
'GradleCompilerRunner#buildModulesInfo'.
#KT-24938 fixed
Bound references require kotlin-reflect 1.1.x on runtime.
However old Gradle versions (e.g. 3.4) can leak 1.0.x reflect
into Gradle classloader, so getting bound reference fails on runtime
(in this case the plugin couldn't connect to the daemon).
Previous plugin resolution mechanism was only searching
for exact artifact without transitive dependencies.
The configuration allows resolving transitive dependencies,
but it resolves stdlib which fails because the compiler
loads plugins using parent last classloader.
Non-transitivity can be removed after parent last classloader is
removed.
We cannot create kapt configurations in `KotlinGradleSubplugin.apply`,
because `apply` is invoked after a script is evaluated, so user cannot
refer to kapt configurations in script.
We cannot call `apply` before script's evaluation, because
then we might not be able to determine
if a Gradle plugin corresponding to a subplugin is appled.
For example in case of the following script:
```
apply plugin: "kotlin"
apply plugin: "kotlin-kapt"
```
subplugin's apply will exit early because Gradle plugin "kotlin-kapt"
is not applied yet, when "kotlin"'s apply is evaluated.
since it causes numerous classloading issues. Using the wrapping types
and reload them in the proper context when needed.
Note: this version supports only classes, but the wrapping type could
be extended to support other types in the future.
+ numerous fixes related to proper loading and handling of the templates.
Also remove these option providers from the javac task compiler argument
providers so as to avoid output intersections of javac vs kapt.
The options generated by the providers are added to the Kapt subplugin
options as well in order to be passed to Kapt. Since these options
are a list, not a map, pass them without name (Kapt should decode them
into plain arguments). Remove the '-A' prefix as it is there for
command line annotation processor options, but we don't need it, it
is added by Kapt internally.
Issue #KT-23964 Fixed
Issue #KT-24420 Fixed
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
Yan Zhulanow