Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
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
but only explicitly. This does not fix a breaking change described in
#KT-52120, because it seems the correct behavior, but it allows
to "workaround" the problem by specifying nullability explicitly.
Also improve handling of nullable bindings in JSR-223.
#KT-49173 fixed
#KT-51213 fixed
Apply the property to the default JSR-223 script taking the value from
java.specification.version property, so effectively implementing
jvmTarget detection from current VM.
Also drop enforcing of target 1.8, using common default.
#KT-49329 fixed
#KT-40497 fixed
now regular, unshaded libs, are named with suffix `-unshaded`, while
former `-embeddable` ones named without any suffix. This will encoursge
use of the shaded libs by default, avoiding conflicts with 3-party
libs packed into the `kotlin-compiler`.
Note, that only the "frontline" libs are renamed to avoid switching
problems, the ones that not normally used directly are left as is,
including the `kotlin-compiler` itself.
so the REPL remain operational after exception in one of the snippets:
- separately return script class and script instance on evaluation (
because in case of an exception the class is valid, while the instance
is not).
- store both the class and the instance in the history
- handle this data accordingly
Dependencies on :kotlin-compiler should never be used in configurations
which are imported transitively because ide fails to import it as
project dependency. When :kotlin-compiler dependency is imported as
kotlin-compiler.jar dependency ide re-indexes it on every change. This
behaviour is super annoying.
#KT-31120 Fixed
Yahor Berdnikau