For some reason gradle processes "testJar" task differently and collects
artifacts for it during configuration phase. This helps Idea project
configurator understand that there's no need to attach test jar as separate
binary library dependency.
Having compiled module in dependencies results IDEA finds both compiled and
source version of classes. This may cause bad navigation and reindexing.
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.
... and invoke it directly in kotlin-reflect's build file, instead of
running another instance of compiler to evaluate a script. Also only
strip kotlin.Metadata, since it's the only annotation with heavy
metadata on Kotlin-generated class files
Rollback tests-jar configuration to extend testCompile instead of testRuntime.
Otherwise an unwanted main artifact from the runtime configuration gets added to the
artifacts of tests-jar configuration.
Exclude transitive dependencies of projectTests(":idea")
`tests-jar` configuration now extends testRuntime instead of testCompile
(note that testRuntime extends testCompile),
and projectTests() dependency shortcut makes it transitive.
This is required to depend on test utility modules producing `-tests` jar instead of default one
without listing all their transitive dependencies.
the task takes a jar an a shading task (like the one that creates embeddable
compiler) and rewrites jar's dependencies to the shaded ones according the
the shade task.
Build parameters (with corresponding project properties):
- build.number (buildNumber) - build number from build server, goes into manifest, by default snapshot
- deployVersion (kotlinVersion, project.version) - version of artifacts, by default build.number
- bootstrap.kotlin.version (bootstrapKotlinVersion) - version of bootstrap compiler
Instead, rework the (already suspicious) KotlinPaths-finding code in
PathUtil to support the new model of running tests (the compiler is
split into several jars according to the project structure) instead of
the old one (where class files were not in the jars, but in the out/
directory).
This fixes Java9ModulesIntegrationTest
Nikolay Krasko