internal

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.

make inner classes static where possible

Signed-off-by: Steven Crockett <crockett.j.steven@gmail.com>

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.

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.

Remove duplicate vendor from javaVmVersion String

Do not follow symlinks when removing work outputs

Record the ClassLoader associated with each class that is serialized to the instant execution cache, and use this to make class lookup on deserialize faster and to deal correctly with multiple classes with the same name.

Move some ClassLoader lifecycling from Groovy DSL script compilation to `ClassLoaderScope`, so that the scope takes care of creating and caching the script ClassLoader.

Support plugins {} in settings scripts

Move Deleter interface out of impl package

Use Deleter when removing the output for Groovy script compilation

Revert "Revert "Let instant execution reuse classloaders when loading""

Re-allows multiple `plugins` blocks in the Groovy DSL

Simplify ScriptCompiler.compile() contract

Not requiring the ClassLoader anymore but only the ClassLoaderScope

as all implementations now use the export loader from the given scope.

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

Apply `Merge identical catch branches` inspection the whole project

Artificially create a class loader scope for Groovy script classes

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

Move ClassLoaderHierarchyHasher to :hashing

Adds constraints to the use of plugins and pluginManagement blocks

Provide the line-number of the plugins block when invoking

Polish `InitialPassStatementTransformer`

- Add documentation comment

- Extract explaining methods

- Remove unnecessary `else` clauses to simplify control flow

Execute the `plugins` block in order to extract plugin requests

Previously, we were extracting `PluginRequests` when compiling a build script,

using AST transforms. This prevented any sort of dynamic behaviour within the

plugins block, such as reading plugin versions from a properties file.

This behaviour was by design, and the syntax of the plugins block was explicitly

restricted to ensure the plugin requests were statically defined.

This restricted syntax has been the cause of much user angst, and the expected

benefits of a truly imperative plugins block have not eventuated. Furthermore,

the implementation of `plugins` in the Kotlin DSL does not add the same

restrictions.

With this change, the `plugins` block is actually invoked to extract any plugin

requests. While the restricted syntax remains (for now), this change opens up

the possibility of supporting property replacement for version numbers and other

dynamic behaviour.

One limitation of this change is that the line number of each plugin request

is not captured correctly: the line number is always reportes as 0 for any

request. Several tests are failing due to this limitation.

Add missing @Override to public api types

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

spelling: prefer

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>