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
(cherry picked from commit 2d41c7d462)
This is needed only for faster compilation of the Kotlin project itself
and has no effect on the public artifact
org.jetbrains.kotlin:kotlin-reflect.
The problem this is solving is the rebuild of the project once anything
has been changed in modules in 'core' (even inside function bodies, i.e.
a non-API change). Previously, changes in 'core' led to the compilation
of kotlin-reflect, which led to the rebuild of all modules depending on
kotlin-reflect directly or indirectly (which is almost all modules in
the project) because kotlin-reflect's artifacts are custom-built and the
changes can not be picked up incrementally. But 99.9% of the time the
initial changes in 'core' could not have any effect on the usages of
kotlin-reflect, because classes from those modules are moved to an
internal package in kotlin-reflect and thus are an internal
implementation detail.
Now, changes in 'core' still lead to the compilation of kotlin-reflect
and to the process of building the custom jar. But if a module depends
on kotlin-reflect-api, not kotlin-reflect, then the incremental
difference checker will detect that the module does not have to be
recompiled if there hasn't been any changes to the API of
kotlin-reflect-api. Which means that the module will not be rebuilt on
every change in 'core'.
This commit only introduces the new module. The dependencies
(kotlin-reflect -> kotlin-reflect-api) are replaced in the next commit.
Required as a workaround for Proguard bug
https://sourceforge.net/p/proguard/bugs/664/
When processing bytecode generated by Kotlin compiler for constructor
call with stack spilling during arguments evaluation, ProGuard performs
an equivalent transformation for the bytecode, but emits invalid stack
frame information.
In JVM 1.6, such invalid stack frames are ignored and re-evaluated by
JVM during bytecode verification.
In JVM 1.8, such invalid stack frames cause VerifyError.
This is needed to avoid the split package problem on Java 9 (KT-19258):
both kotlin-stdlib.jar and kotlin-reflect.jar export the package
kotlin.reflect
The idea is to keep all declarations in the same packages from Kotlin's
point of view, but use JvmPackageName annotation to move them to another
JVM package, to avoid the split package problem which is otherwise
unsolvable when using module path on Java 9 (KT-19258).
In this commit, kotlin-stdlib-jre7/8 are moved to kotlin-stdlib-jdk7/8
and in the subsequent commit, -jre7/8 are restored. This is done in
order to make Git recognize this as a file move to preserve history.
Include new stdlib-jdkN artifacts in manifest version tests.
- suspendCoroutine is not public anymore, since all of the
inline functions are generated as private
- `label` is public to allow update it from the named functions
Produce special stdlib artifact with annotations for dist.
Put js outputs to dist, they're required for JS backend tests.
Use kotlin-compiler for maven, which has all required dependencies bundled.
Clean local directory repository on clean.
Change paths in tests to compiled artifacts.
