Creating javadocJar task for every project produces lots of unnecessary
tasks, some project don't even have code. Jar task without outDir
property set fails idea import with gradle 5.0+
Provide additional modular artifacts as a workaround for KT-21266
Update module-info declarations:
- add new packages
- add exports and opens for internal PlatformImplementations
- remove exports of kotlin.coroutines.experimental.*
#KT-27919 Fixed
Do not pass the jars for modules such as descriptors, descriptors.jvm,
etc to `--module-path` because javac assumes that these are separate
modules (even though they're listed later as parts of this module in
`--patch-module), and prohibits to have split packages and foreign
service implementations among them
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
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
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
Switching to in-process to avoid compilation warnings caused by introduced
daemon interface changes.
Switching to the gradle plugin 1.1.3 causes jansi incompatibility in
in-process compilation mode, so disabling jansi usage to avoid it.
Add option to disable signing (-PnoSign), to be used when publishing
pre-built artifacts
Add option to define specific version for publishing, to be used when
publishing test versions
(cherry picked from commit dcd55e9)
* Fix Java not compiled in kotlin-gradle-plugin Kotlin source set
* Fix the integration tests running under Java 6
* Fix kotlin-gradle-subplugin-example not being installed -- needed
for a test
* Fix Android tests being always excluded
* Move versions out of `build.gradle` (x2) to a common `versions.gradle`
* Move JDK, dist and bootstrap to `commonConfiguration.gradle`
* Build `kotlin-gradle-plugin` with JDK_18
* Add gradle-tools subproject
* Add Gradle buildscripts to the related projects
* Remove the projects from the libraries pom.xml
* Move AndroidGradleWrapper.groovy to separate source root
* Changed artifact dependencies to project dependencies where needed
* Extract common configuration into commonConfiguration.gradle
* (convert functions to closures to be able to call them)
* Refactor DSL usage
* Replace `project.properties` with `findProperty`
* Unify Gradle wrapper between `libraries` and `gradle-tools`
(as a temporary solution, just made the wrapper files the same)
Vyacheslav Gerasimov