Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Do not hash the implementation classpath for a Groovy DSL script to use for in-memory script caching, but instead use the parent `ClassLoader` identity and the hash of the script itself, as this is faster and identifies the script implementation equally well.

This was the previous behavior, which was accidentally changed in a previous commit. This commit restores the previous behaviour but in a way that (hopefully) is harder to accidentally break in the future.

  1. … 8 more files in changeset.
Do not hash the implementation classpath for a Groovy DSL script to use for in-memory script caching, but instead use the parent `ClassLoader` identity and the hash of the script itself, as this is faster and identifies the script implementation equally well.

This was the previous behavior, which was accidentally changed in a previous commit. This commit restores the previous behaviour but in a way that (hopefully) is harder to accidentally break in the future.

  1. … 9 more files in changeset.
Do not hash the implementation classpath for a Groovy DSL script to use for in-memory script caching, but instead use the parent `ClassLoader` identity and the hash of the script itself, as this is faster and identifies the script implementation equally well.

This was the previous behavior, which was accidentally changed in a previous commit. This commit restores the previous behaviour but in a way that (hopefully) is harder to accidentally break in the future.

  1. … 8 more files in changeset.
Do not hash the implementation classpath for a Groovy DSL script to use for in-memory script caching, but instead use the parent `ClassLoader` identity and the hash of the script itself, as this is faster and identifies the script implementation equally well.

This was the previous behavior, which was accidentally changed in a previous commit. This commit restores the previous behaviour but in a way that (hopefully) is harder to accidentally break in the future.

  1. … 9 more files in changeset.
Add support for locking extension in ScriptHandler

This enables defining the lock mode and other extensions to dependency

locking.

  1. … 3 more files in changeset.
Add support for locking extension in ScriptHandler

This enables defining the lock mode and other extensions to dependency

locking.

  1. … 3 more files in changeset.
Add support for locking extension in ScriptHandler

This enables defining the lock mode and other extensions to dependency

locking.

    • -0
    • +39
    ./main/kotlin/org/gradle/kotlin/dsl/ScriptHandlerExtensions.kt
  1. … 4 more files in changeset.
Add support for locking extension in ScriptHandler

This enables defining the lock mode and other extensions to dependency

locking.

  1. … 3 more files in changeset.
Add support for locking extension in ScriptHandler

This enables defining the lock mode and other extensions to dependency

locking.

  1. … 3 more files in changeset.
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

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

  1. … 870 more files in changeset.
Simplify and improve the reliability of serializing classes to the instant execution cache.

Fixes a case where loading the instant execution cache after writing a task graph that references a different set of build scripts to that referenced last time the task graph was written.

  1. … 7 more files in changeset.
Simplify and improve the reliability of serializing classes to the instant execution cache.

Fixes a case where loading the instant execution cache after writing a task graph that references a different set of build scripts to that referenced last time the task graph was written.

  1. … 5 more files in changeset.
Simplify and improve the reliability of serializing classes to the instant execution cache.

Fixes a case where loading the instant execution cache after writing a task graph that references a different set of build scripts to that referenced last time the task graph was written.

  1. … 7 more files in changeset.
Fix for previous commit.

    • -0
    • +24
    ./main/kotlin/org/gradle/kotlin/dsl/execution/CompiledScript.kt
  1. … 3 more files in changeset.
Fix for previous commit.

  1. … 3 more files in changeset.
Annotate new tests failing with instant execution after merging master

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

  1. … 1 more file in changeset.
Merge branch 'master' into eskatos/ie/instantIntegTest-enable

  1. … 8 more files in changeset.
Prove the new script templates are not missing any members

- prove new init script template is not missing any members from the legacy

`InitScriptApi`

- prove new setting script template is not missing any members from the legacy

`SettingsScriptApi`

Upgrade Kotlin to 1.3.60

  1. … 7 more files in changeset.
Upgrade Kotlin to 1.3.60

  1. … 7 more files in changeset.
Upgrade Kotlin to 1.3.60

  1. … 7 more files in changeset.
Upgrade Kotlin to 1.3.60

  1. … 7 more files in changeset.
Mark `InitScriptApi` and `SettingsScriptApi` deprecated

And provide a suggestion to `replaceWith` the corresponding script receiver.

Fix for previous commit.

  1. … 2 more files in changeset.
Fix for previous commit.

  1. … 2 more files in changeset.
Fix `ClassNotFoundExeception` when loading objects whose class is defined in a build script from the instant execution cache, after recreating the cache from a daemon process that has previously successfully used the cache.

For example, running `gradle taskA`, `gradle taskA`, `gradle taskB`, `gradle taskB` would fail if `taskB` uses types from a build script.

This was happening because the script ClassLoaders are cached and reused, but the association between ClassLoader and scope was lost, and this association is what instant execution uses to know how to load the class.

This change fixes one case of this problem, but the same problem can still happen if the set of build scripts being referenced changes.

  1. … 19 more files in changeset.
Fix `ClassNotFoundExeception` when loading objects whose class is defined in a build script from the instant execution cache, after recreating the cache from a daemon process that has previously successfully used the cache.

For example, running `gradle taskA`, `gradle taskA`, `gradle taskB`, `gradle taskB` would fail if `taskB` uses types from a build script.

This was happening because the script ClassLoaders are cached and reused, but the association between ClassLoader and scope was lost, and this association is what instant execution uses to know how to load the class.

This change fixes one case of this problem, but the same problem can still happen if the set of build scripts being referenced changes.

  1. … 16 more files in changeset.
Fix `ClassNotFoundExeception` when loading objects whose class is defined in a build script from the instant execution cache, after recreating the cache from a daemon process that has previously successfully used the cache.

For example, running `gradle taskA`, `gradle taskA`, `gradle taskB`, `gradle taskB` would fail if `taskB` uses types from a build script.

This was happening because the script ClassLoaders are cached and reused, but the association between ClassLoader and scope was lost, and this association is what instant execution uses to know how to load the class.

This change fixes one case of this problem, but the same problem can still happen if the set of build scripts being referenced changes.

    • -0
    • +24
    ./main/kotlin/org/gradle/kotlin/dsl/execution/CompiledScript.kt
  1. … 19 more files in changeset.
Fix `ClassNotFoundExeception` when loading objects whose class is defined in a build script from the instant execution cache, after recreating the cache from a daemon process that has previously successfully used the cache.

For example, running `gradle taskA`, `gradle taskA`, `gradle taskB`, `gradle taskB` would fail if `taskB` uses types from a build script.

This was happening because the script ClassLoaders are cached and reused, but the association between ClassLoader and scope was lost, and this association is what instant execution uses to know how to load the class.

This change fixes one case of this problem, but the same problem can still happen if the set of build scripts being referenced changes.

    • -0
    • +23
    ./main/kotlin/org/gradle/kotlin/dsl/provider/CompiledScript.kt
  1. … 16 more files in changeset.
Polish `DefaultKotlinScript`

- Reduce scope of unchecked_cast annotation