Facet serialization is located in Kotlin repo, and it uses new(1.9.*) stdlib in compile dependencies. But when it is used by IJ it has previous runtime stdlib dependency (looks like 1.8.0). So here is workaround, that specifies apiVersion and languageVersion, that does not produce such problematic outputs.
#KTIJ-24903 Fixed
Merge-request: KT-MR-9333
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Review: https://jetbrains.team/p/kt/reviews/6753
Meaningful semantic change was splitted into 5 commits to simplify the
change review. Sinle commit would be too big.
Why replace source to binary: to get rid of kotlin-reflect in Kotlin
plugin artifact KTIJ-22276
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
Before this commit `jps/jps-*/build.gradle.kts` list of dependencies
were partially duplicated in the `compilerModulesForJps`
Right now, list of all JPS dependencies is the source of truth.
Actually, I wish I could it do it the other way around -- let the Gradle
do dependency management and correctly produce jars with as less as
possible other libraries being embedded, and as much as poosible
libraries being just dependencies in the pom.xml.
I tried to do so using `embedded` and self-made configurations but
desperately failed, because was getting to big
`kotlin-jps-plugin-classpath` jar. Probably, what I was getting is a
correct classpath, and currently hardcoded classpath may not be
correctly full. Well, at least current classpath is time-proven.
- Some unnecessary dependencies are dropped
- `api` is replaced with `implementation` when it's more appropriate (in
our case more appropriate everywhere). `implementation` makes it
easier to analyze dependencies because it doesn't export the
dependencies
- Regarding: `// Workaround for Gradle dependency resolution error`.
Actually, it's not longer needed for the successful project import.
Confirmed by Yahor and tested locally.
'AbstractCompile' task has inputs that are related only to Java
compilation and should not used for Kotlin compile tasks.
'SourceTask' most probably will be deprecated in future Gradle releases
- https://github.com/gradle/gradle/issues/9040. Plus it has
old 'sources' with 'FileTree' type which is not stable
for task inputs snapshotting.
Another breaking change - 'destinationDir' task property is not longer
available. It is replaced by 'destinationDirectory' which uses Gradle
Provider API type.
^KT-32805 In Progress
IntelliJ uses Java 11 so it forces us to use Java 11 in JPS
This commit fixes:
```
public class DataContainerVersionChangedTestGenerated extends AbstractDataContainerVersionChangedTest {
^
bad class file: /home/bobko/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.platform/test-framework/203.8084.24/ba5c6b3b0eae0a083dc30e866c362094f5072853/test-framework-203.8084.24.jar(com/intellij/testFramework/UsefulTestCase.class)
class file has wrong version 55.0, should be 52.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
```
Up-to-date check is very heavy for intellij repo due to artifact size.
If module directory in repo is written only by one task we can assume
that task if up-to-date if target directory exists.
Original commit: fc8be48fa8
- support common modules metadata compilation under flag (it is not required since all common source roots are included transitively for now)
- introduce expect actual tracker in jps: move implementation from gradle to build-common
- support js incremental compilation: move implementation from gradle to build-common
Original commit: 0eee2729cd
Use distJar configuration instead.
It's necessary because currently when using default-type, subproject
starts having a transitive dependency to :kotlin-stdlib-common
and that leads to exception from KT-20897 when building light classes
This change might be reverted once KT-23942 is fixed
#KT-23942 Submitted
Original commit: 003f381fcd
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Original commit: 8a82c1618c
Roman Golyshev