Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add missing `@Incubating` annotation

Make `Project.plugins { }` extension a top-level function

Fail to compile nested `plugins` blocks in Kotlin scripts

  1. … 1 more file in changeset.
Fail to compile nested `plugins` blocks in Kotlin scripts

  1. … 1 more file in changeset.
Polish ResolverEnvironment

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove now unused ResolverAction.Return

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove now unused ResolverAction.Return

Signed-off-by: Paul Merlin <paul@gradle.com>

Polish ResolverCoordinatorTest

Signed-off-by: Paul Merlin <paul@gradle.com>

Polish ResolverCoordinatorTest

Signed-off-by: Paul Merlin <paul@gradle.com>

Put short-circuit behing an IDE flag

Next IJ release will make use of that flag.

It is unset by default, disabling the reintroduced short-circuit,

in order not to break users of existing IJ versions.

Signed-off-by: Paul Merlin <paul@gradle.com>

Put short-circuit behing an IDE flag

Next IJ release will make use of that flag.

It is unset by default, disabling the reintroduced short-circuit,

in order not to break users of existing IJ versions.

Signed-off-by: Paul Merlin <paul@gradle.com>

Prefer `Action<T>` over `T.() -> Unit` for the Kotlin script API

From the perspective of an user of the API both types are effectively

the same.

From a compile time and runtime perspective `Action<T>` seems a better

choice as values can be passed to the core Gradle API directly.

From an API consistency point of view `Action<T>` also looks like the

superior choice as it is more consistent with the rest of the Gradle

API.

And finally, from an user education perspective, `KotlinScript`

provides a clear opportunity for users to understand the equivalence

between `Action<T>` and `T.() -> Unit`.

Polish `ScriptApiTest`

Polish `ResidualProgramCompilerTest`

- Remove spurious empty line

Let precompiled script templates support the `ObjectConfigurationAction` syntax

  1. … 1 more file in changeset.
Polish `PrecompiledScriptTemplates.kt`

- Reduce member visibility

Let precompiled project script template support `ObjectConfigurationAction` syntax

  1. … 1 more file in changeset.
Remove deprecation from script template used for content assistance

Polish `ResidualProgramCompiler`

- Add message to TODO exception

- Reduce member visibility

Move deprecation explanation from KDOC comment into annotation

Remove `ScriptApi` interface and use `KotlinScript` instead

Restore Kotlin DSL script deps resolver short circuit

Signed-off-by: Paul Merlin <paul@gradle.com>

Restore Kotlin DSL script deps resolver short circuit

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove deprecation of classes still used by the IDE script templates

Polish `KotlinSettingsScriptIntegrationTest`

Let compiled Kotlin script templates implement `PluginAware` by delegation

In order to enable `ObjectConfigurationAction` syntax (`apply {... }`)

and to preserve file resolving semantics when using a `PluginAware`

extension such as `PluginAware.apply(from: String? = null, ...)` -

init and settings scripts resolve the applied script file relative to

the applying script.

    • -0
    • +45
    ./main/kotlin/org/gradle/kotlin/dsl/support/PluginAwareScript.kt
Polish `TestWithCompiler`

- Reuse `PluginManagementSpec` mock

Let `CompiledKotlinBuildScriptAndPluginsBlock` script template implement the Kotlin script API

Polish `ParserToCompilerTest`

Let `pluginManagement` Kotlin script template have an implicit `Settings` receiver