After shadow is updated to 7.1.1, library ComponentsXmlResourceTransformer
should work fine.
The only reason for this patched version was the bug that was fixed in 7.1.0:
https://github.com/johnrengelman/shadow/releases/tag/7.1.0
^KTI-733 Fixed
Version 7.1.1 is absent in jcenter, so additional repository was added
in some modules.
Leave old version in NewMultiplatformIT.kt because of
`This version of Shadow supports Gradle 7.0+ only. Please upgrade.` error.
^KTI-733 Fixed
Don't read absent file with disabled plugins during creating Kotlin
core environment.
Exception in thread "main" java.lang.NullPointerException
at java.io.Reader.<init>(Reader.java:78)
at java.io.InputStreamReader.<init>(InputStreamReader.java:113)
at com.intellij.ide.plugins.PluginManagerCore.readBrokenPluginFile(PluginManagerCore.java:249)
at com.intellij.ide.plugins.PluginManagerCore.getBrokenPluginVersions(PluginManagerCore.java:241)
at com.intellij.ide.plugins.PluginManagerCore.createLoadingResult(PluginManagerCore.java:822)
at com.intellij.ide.plugins.DescriptorListLoadingContext.createSingleDescriptorContext(DescriptorListLoadingContext.java:64)
at com.intellij.ide.plugins.PluginManagerCore.registerExtensionPointAndExtensions(PluginManagerCore.java:1318)
at com.intellij.core.CoreApplicationEnvironment.registerExtensionPointAndExtensions(CoreApplicationEnvironment.java:287)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerApplicationExtensionPointsAndExtensionsFrom(KotlinCoreEnvironment.kt:622)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createApplicationEnvironment(KotlinCoreEnvironment.kt:592)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForTests(KotlinCoreEnvironment.kt:505)
at org.jetbrains.kotlin.android.tests.CodegenTestsOnAndroidGenerator$FilesWriter.writeFilesOnDisk(CodegenTestsOnAndroidGenerator.kt:214)
at org.jetbrains.kotlin.android.tests.CodegenTestsOnAndroidGenerator$FilesWriter.writeFilesOnDiskIfNeeded(CodegenTestsOnAndroidGenerator.kt:208)
It's not used by now, and there's are known problems with it check
KTI-712.
If transition to JUnit5 is needed, creating another module might
be a better option.
Note: there might be a performance issue with running tests,
the reason why custom filtering was added to the tests running.
It's not tested and should be addressed separately
Try run IrBlackBoxCodegenTestGenerated.Annotations. Everything in the
outer class IrBlackBoxCodegenTestGenerated is run instead.
This is not an IDEA problem, since it reproduces from
the command line too.
^KTI-712 Fixed
Previously actual value was dependent on the order of calls to `updateJvmTarget` and `configureJava9Compilation` in build script that may lead to inconsistencies
Before this change buildSrc module was compiled with current user JDK.
For example on CI it is JDK 1.8. But when the user is using JDK
different from 1.8, buildSrc compilation misses remote build cache. This
may lead to full project recomplilation on the user side.
Usually, java 9 source sets contain only module-info.java file, so
Kotlin compilation does not run because there are no .kt sources.
However, it can still start after some incremental changes and
thus it's important to have its JVM target configured consistently
with Java compilation of the same source set.
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
The reason is that when advancing language version, for example from 1.5
to 1.6, there is a brief period between bootstraps where the
bootstrapped compiler has latest stable language version 1.6, yet the
project is still built with 1.5. That leads to a (correct) warning that
progressive mode makes no sense unless the latest language version is
used, which fails the build because of Werror.
When testing bootstrap in progressive mode, we don't actually care about
these warnings, so disable Werror in this case.
The only case where this could matter would be if we were introducing
_warnings_ in progressive mode and checking that there are no new
warnings on Kotlin would be important for us, but so far progressive
mode has only been used to turn already existing warnings to errors.
Ilya Gorbunov