Actually we don't need javadoc generation for our internal stuff like
':kotlin-gradle-plugin'. But ':kotlin-gradle-plugin-api' is a public api
and should have properly generated javadocs.
^KT-55520 In Progress
Old one is deprecated and delegates to new options. All new options
are marked with task input types, so they could be used as `@Nested`
input.
Generated options are using specific types in generated
compiler options. This should simplify code completion and provide
meaningful hints to user.
At this point repository compilation will fail.
^KT-27301 In Progress
This is used twofold:
1) The dependsOnClosure and withDependsOnClosure can be accessed
w/o any additional overhead
2) This can later be used to maintain caches for a
replacement of the slow compilationsBySourceSet util
KT-52726
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
- Rename IdeaKpmProjectModelBuildingContext to IdeaKpmProjectBuildingContext
- Support building IdeaKpmProjectContainer
- Implement IdeaKpmSerializationContext on Gradle side
^KT-52568 In Progress
Such dependencies will be embedded into plugin jar and their package
will be relocated. This is need to avoid dependency conflicts with
user build scripts dependencies or other Gradle plugins.
Kotlin project dependencies are not shadowed.
^KT-46034 Fixed
This dependency brings gradleApi as a transitive dependency, which leads
to false-positive deprecation errors in plugin variants.
^KT-47047 In Progress
Simplifies and make it aligned with official documentation, which
removes some old workarounds. Additionally, it enables publication of
Gradle metadata file, which is required for plugin variants feature
support.
Instead of using 'gradleApi()' as Gradle API dependency, which provides
build current Gradle version api, now setup is using
"dev.gradleplugins:gradle-api" artifacts with specific Gradle version.
This allows to have more fine-grained Gradle support for removed apis.
^KT-49227 In Progress
- Introduce `kotlin-gradle-plugin-idea` module that allows
to share models between the IDE and KGP
- Add `kotlin-gradle-plugin-idea` to the RuntimePublicAPITest to
ensure binary compatibility
^KT-51262
When in 'lenient' or 'classpath' mode, Gradle will catch exceptions
during project evaluation and collect them into the
'ClassPathModeExceptionCollector'.
Running checks on the project after evaluation should only happen
if the project is properly configured (aka no such exceptions collected)
to prevent false positive error reports (that will then fail
the Gradle process and swallow the real cause)
^KT-48823 Verification Pending
Martin Bonnin