In Gradle 4.10.2, a change was made in the attributes disambiguation
process: if some of the candidates have a single attribute value and
others don't have that attribute (i.e. have a null value), the
disambiguation rule for that attribute doesn't get called.
Effectively, null values are excluded from disambiguation, but still may
cause ambiguity (sic!)
See: https://github.com/gradle/gradle/issues/6747#issuecomment-445921139
This change affected our attribute `localToProject` that we use to
disambiguate the deprecated but still consumable configurations like
`compile`, `runtime`, `testCompile`, `testRuntime` from those
configurations which should have priority during project dependency
resolution: the `*Element` ones. Our scheme marked the former
configurations with the attribute and the latter were not marked, with
a disambiguation rule that preferred null values.
To fix this logic with Gradle 4.10.2, we instead mark both kinds of
configurations with the attribute, which now has a value 'public'
that is preferred by the rule over the other values. We also make sure
that the attribute doesn't leak into the published Gradle metadata, as
it is only needed for project-to-project dependencies resolution.
Issue #KT-28795 Fixed
In Gradle 5.0, iterating over the `.withType<...>()` result below
caused a ConcurrentModificationException. Workaround that by first
collecting the items into a list.
* Introduce GradleVersionRequired.InRange and thus prevent older
tests (e.g. Android 2.3.0) from running with newer Gradle versions
* Add a task outputs pattern suitable for Gradle 5.0
* Run some of the Android tests with AGP 3.1.0 (and Gradle 4.4) instead
of 3.0.0 to ensure compatibility with Gradle 5.0
* Update test projects according to Gradle 5.0 dropped deprecated
features: classesDir, left-shift operator, default org.gradle.util.*
imports
* Fix a Gradle test after Gradle 5.0 changed `publishing` behavior to
run the closure eagerly rather than after evaluation
AP discovery in compile classpath can be disabled in all subprojects
by adding "kapt.include.compile.classpath = false" to 'gradle.properties' file.
KT-24530
The setting can be overrided per project by using KAPT DSL
in a 'build.gradle' file:
```
kapt {
includeCompileClasspath = false
}
```
#KT-28852 fixed
The loaders and hence some classes were repeatedly loaded and
jit-compiled everytime when KaptExecution were dispatched. Those
classes, like JavaCompiler, can be very large and therefore created a
significant overhead. In some projects, the overhead accounted for more
than 40% of total CPU time of annotation processing.
This change tries to cache the classloaders so that they won't be
reloaded and re-jitted.
The compiler uses thread local values,
so when the compiler runs Gradle's thread,
it leaks classes preventing
a compiler's classloader from being collected.
#KT-28037 fixed
CharBuffer had capacity to hold 2 chars, which was not enough to append
a surrogate pair when the buffer was not empty.
The buffer was extended and the decoding algorithm rewritten to deal with
a buffer of any length.
#KT-28572 Fixed
Workaround for IDEA-200192:
IDEA makes all JavaExec tasks not up-to-date and attaches debugger making our breakpoints trigger during irrelevant task execution
Place them in tests of kotlin-test-annotations-common, so that every
platform module that implements that common module (e.g. kotlin-test-junit,
kotlin-test-junit5, kotlin-test-testng) gets these tests run.
Improve test for BeforeTest/AfterTest annotations to check that they are
invoked before/after _each_ test method.
#KT-27629
Given the prior faulty logic, no tree of `HierarchyAttributeContainer`s would ever report itself as empty (not even a 'tree' consisting of a single, attribute-less/empty HierarchyAttributeContainer), since every tree will have a root, which will lack a parent, and it considered the lack of existence of a parent to mean that that root container is not empty.
In Gradle 5.0, the `publishing` extension is configured eagerly, so
we need to make sure everything we use in publishing setup is already
available at the point when it's triggered:
* the `metadata` target
* the source JARs
Issue #KT-28520 Fixed
Make compiler plugin options evaluate lazily, with Lazy<String> and
FileCollection as replacements for the eagerly-evaluated data.
Adjust compiler plugin option usages so that their evaluation is not
triggered when not necessary.
Issue #KT-26065 Fixed
Now it already included. Manually including causes duplicated contents
in resulting files, for example:
1 kotlin.reflect.jvm.internal.impl.load.java.FieldOverridabilityCondition
2 kotlin.reflect.jvm.internal.impl.load.java.ErasedOverridabilityCondition
3 kotlin.reflect.jvm.internal.impl.load.java.JavaIncompatibilityRulesOverridabilityCondition
4 + kotlin.reflect.jvm.internal.impl.load.java.FieldOverridabilityCondition
5 + kotlin.reflect.jvm.internal.impl.load.java.ErasedOverridabilityCondition
6 + kotlin.reflect.jvm.internal.impl.load.java.JavaIncompatibilityRulesOverridabilityCondition
Removing this line fixes that.
Previously this files was stored in /src directory and was included in
resources mainly by SourceSet.projectDefault from sourceSets.kt:
val processResources = tasks.getByName(processResourcesTaskName) as ProcessResources
processResources.from("resources") { include("**") }
processResources.from("src") { include("META-INF/**", "**/*.properties") }
Also there are some custom rules like this:
resources.srcDir("../idea-analysis/src").apply { include("**/*.properties") }
resources.srcDirs("idea-repl/src").apply { include("META-INF/**") }
All this rules are synthesized in script
https://github.com/snrostov/kotlin-migrate-resources/blob/master/src/main/kotlin/main.kt
This commit created using that script. See README.md for more details on
script.
Shagen Ogandzhanian