KotlinScriptClassPathProvider.kt

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Convert to multi-project build in preparation to adding new modules

See #304

    • -152
    • +0
    ./KotlinScriptClassPathProvider.kt
  1. … 263 more files in changeset.
Tighten exported API

This commit adds `internal` or `private` to internal members

The only exported API that includes Gradle internals is now in .provider

See #209

  1. … 23 more files in changeset.
Dedupe script classpath computation

    • -24
    • +24
    ./KotlinScriptClassPathProvider.kt
  1. … 4 more files in changeset.
Polish

- Normalise placement of `private`, `protected`, `internal` and

`inline` modifiers

  1. … 42 more files in changeset.
Compute parent classpath via `ClasspathUtil#getClasspath`

See #190

  1. … 3 more files in changeset.
Polish KotlinScriptClassPathProvider

kotlin-runtime is no more

Handle `HasImplicitReceiver` annotation via Kotlin compiler plugin

See #155

  1. … 22 more files in changeset.
:arrow_up: Kotlin 1.1-M04 :tada:

See #211

  1. … 3 more files in changeset.
Polish top-level definitions, parameter lists and exceptions

* Separate top-level definitions by two lines

* Segregate visibility modifier of top-level definition to

its own line

* Prefer starting long parameter lists at the next line (more

sustainable in face of method renames)

* Remove unnecessary `Exception` suffix from class names

* Remove unnecessary prefixes from field names

* Use better name for exception variables

  1. … 38 more files in changeset.
Generate builtin plugin id extensions

See #168

  1. … 9 more files in changeset.
Support the `plugins` block :tada:

We use a new type - `KotlinPluginDependenciesHandler` - as the target

for the top-level plugins block instead of the core type

`PluginDependenciesSpec` so we can annotate it with a `@DslMarker`

annotation - `@BuildScriptBlockMarker` - in the hopes that once IntelliJ

starts recognising it, the code completion experience will be better.

Better documentation comments and validation will come in subsequent

commits.

See #186

  1. … 10 more files in changeset.
Report API jar generation progress

Resolves #116

    • -12
    • +28
    ./KotlinScriptClassPathProvider.kt
  1. … 10 more files in changeset.
Extract `ApiJar` and `ApiExtensionsJar` modules

See: #117

  1. … 7 more files in changeset.
Support navigating to generated extensions sources

See #117

    • -17
    • +43
    ./KotlinScriptClassPathProvider.kt
  1. … 4 more files in changeset.
Polish `KotlinScriptClassPathProvider`

    • -12
    • +12
    ./KotlinScriptClassPathProvider.kt
Include gsk version in the name of generated jars

So they are regenerated whenever a different gsk version is used.

  1. … 1 more file in changeset.
Generate Action<T> extensions at runtime

This ensures the generated extensions match the Gradle API being used by

the build script.

See: #117

  1. … 10 more files in changeset.
Re-enable gradle-script-kotlin-api jar generation

  1. … 2 more files in changeset.
Move codegen code to main source set

Mainly to work around a loader constraint violation that appeared when

updating to the latest snapshot.

In the long run it makes sense to have the code available in the

distribution for when we implement code generation at the project site.

Temporarily disable Kotlin API generation until the Action extensions

can be generated again.

Temporarily disable checking the `copy` sample until the Action

extensions are available.

  1. … 25 more files in changeset.
Address code review feedback from @cbeams

- Rename `requiresExtension` to `conflictsWithExtensions`

- Rename `eraseMethodsMatching` to `removeMethodsMatching`

  1. … 7 more files in changeset.
Generate gradle-script-kotlin-api jar atomically

See #52

Compile scripts against generated Kotlin API jar

We would like Kotlin build scripts to behave as if all the `Action<T>`

parameters in the Gradle API had been declared as `T.() -> Unit` to

avoid the need for explicitly qualifying the single argument to the

given lambda expressions with `it`.

In other words, we would like users to be writing code like:

copySpec {

from("src")

into("out")

}

Instead of:

copySpec {

it.from("src")

it.into("out")

}

Where `copySpec` is declared in the Gradle Java API as:

CopySpec copySpec(Action<? super CopySpec> configuration)

So far we have been able to avoid the qualifying `it` in some situations

via mindful use of inheritance and Kotlin extensions but a comprehensive

solution was still lacking. The underlying issue is that while Kotlin

does provide a type extension mechanism, type members still take

precedence over extensions and currently there's no mechanism to

instruct Kotlin otherwise.

In the future we might be able to implement a different solution to this

particular issue via a new Kotlin language feature still in discussion:

- https://youtrack.jetbrains.com/issue/KT-12848

In the meantime, by giving the Kotlin compiler a carefully crafted API

jar with all members that could potentially conflict with our provided

extensions removed we can work around the fact that interface members

take precedence over extension members and expose all the extensions we

want.

And that is the solution implemented in this commit:

- Remove all API methods that take a last `Action<T>` parameter

- Generate shim extensions that take a last `T.() -> Unit`

Proper treatment for generic types will be implemented in a future

commit.

Resolves: #52

See also: #54, #117

    • -0
    • +103
    ./KotlinScriptClassPathProvider.kt
  1. … 27 more files in changeset.