Using the new multi-release jar feature, store compiled
module-info.class files into META-INF/versions/9 instead of the artifact
root. Hopefully, this will break fewer tools which do not support
module-info.class files because any sane tool should not do anything
with files in META-INF because before Java 9 that directory only
contained resources.
Upgrade some Maven plugins to newer versions which do not fail on
module-info.class files
#KT-21266 In Progress
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Otherwise IC fails when a project declares a class with the same name
as in one of its dependencies.
The issue is relevant only for non-JPS IC (Gradle, Maven, etc.),
but I added the test for JPS too.
#KT-20516 fixed
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
com.android.tools.build:gradle brings about 50 unused transitive dependencies including idea-core and uast, sometimes it breaks IDE features like navigation to declarations and debugging.
Inline contents of ReflectionUtil.findMethod to remove dependency on idea-core
Remove a non-reflective usage of the ResourceSet class, which has been
moved to a different package between versions. Access it through
reflection instead. This is a workaround. We can introduce a proper
fix once we have a public API in the Android plugin.
The test case that could detect the compatibility issue is
`testAndroidExtensionsManyVariants` (it uses experimental Android
extensions), but we did not run it with 3.2.0-alpha6. This commit
adds a test class with the same tests for 3.2.0-alpha6.
Issue #KT-23192 Fixed
Alexander Udalov