Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Annotate integ tests failing with instant execution in :baseServices

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

Annotate integ tests failing with instant execution in :baseServices

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

Make paths/names of included builds immutable (#10998)

Changes the “build path” for included builds to be determined at inclusion time based on the directory name, or a user supplied override. Previously, we tried to use the root project name defined in the included build. This caused a lot of complexity due to it not being known until part way through building the included build.

This change also disallows use of `buildSrc` as a project name, as it collides with the `buildSrc` nested build.

  1. … 72 more files in changeset.
Fix test

Synchronize access to System Properties when creating SSLContexts

  1. … 2 more files in changeset.
Synchronize access to System Properties when creating SSLContexts

  1. … 2 more files in changeset.
Fix tests

Rework task logger build id decoration

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

  1. … 1 more file in changeset.
Simplify tests that look for rich content in the console output.

  1. … 16 more files in changeset.
Simplify tests that look for rich content in the console output.

  1. … 16 more files in changeset.
Simplify tests that look for rich content in the console output.

  1. … 16 more files in changeset.
Simplify tests that look for rich content in the console output.

  1. … 16 more files in changeset.
Simplify tests that look for rich content in the console output.

  1. … 16 more files in changeset.
Simplify tests that look for rich content in the console output.

  1. … 16 more files in changeset.
Remove synchronization around all system property getters

  1. … 5 more files in changeset.
Decorate task logger with build operation id so usage from external thread is linked to correct task

  1. … 3 more files in changeset.
Decorate task logger with build operation id so usage from external thread is linked to correct task

  1. … 3 more files in changeset.
Decorate task logger with build operation id so usage from external thread is linked to correct task

  1. … 3 more files in changeset.
spelling: enqueuing

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

Signed-off-by: Bo Zhang <bo@gradle.com>

  1. … 1 more file in changeset.
Add project lock stats to measure time waiting for locks

  1. … 4 more files in changeset.
Fix file leak in ClassLoaderUtilsIntegrationTest

Fix file leak in ClassLoaderUtilsIntegrationTest

Prevent CMEs when creating Ivy instances

Ivy iterates over the system properties, which may be

mutated at the same time. This change wraps the Ivy call

so that concurrent modifications are forbidden.

Fixes #6175

  1. … 2 more files in changeset.
Separate defineClass and decorateClass (#6028)

After https://github.com/gradle/gradle/pull/5811 is merged, I was surprised that the illegal reflective access warnings still appear:

> Illegal reflective access using Lookup on org.gradle.internal.classloader.ClassLoaderUtils

It turns out that a lookup object which is accessible to the target class class loader must be provided. For example, if we want to invoke `MyClassLoader.defineClass` via `Lookup`, we must provide a lookup object from `privateLookupIn(MyClassLoader.class)`, not `privateLookupIn(ClassLoader.class)`. Otherwise, we'll get the warning and potential failure in the future.

See more information in the https://mydailyjava.blogspot.com/2018/04/jdk-11-and-proxies-in-world-past.html

Also, this PR does a tiny improvement: it uses `Lookup.defineClass` as much as possible. `Lookup.defineClass` is expected to replace `Unsafe.defineClass` by JDK team, but `Lookup.defineClass` has a limitation: it can only `defines a class to the same class loader and in the same runtime package and protection domain as this lookup's lookup class`. If we're decorating a class, this is gonna be fine and we use this API, otherwise we use `Lookup` to invoke `ClassLoader.defineClass` as a fallback.

  1. … 4 more files in changeset.
Rationalise handling of “current” build operation and build operation ID

For an upcoming change to emit console logging as build operation progress events, we need to associate all progress logging with the build operation. This pulled a thread on some long overdue cleanup.

The end result is:

1. Base build operation infrastructure is consolidated org.gradle.internal.operations.

2. Mechanism for passing thread global current build operation is more test friendly, and better named.

3. A consistent mechanism is used for binding the current operation to the thread, instead of two mechanisms.

4. Build operation IDs are typed to OperationIdentifier.

There is no public API or user behaviour change.

  1. … 147 more files in changeset.
Change test to run two successive builds using the GradleBuild task

This test was endangered to be flaky. Running two builds in a row,

there is never a guarantee that they will run on the same daemon.

Clarify that only builds started by a GradleBuild task cause the issue

Add tests for: build operation ids are unique for nested builds

#2622

  1. … 2 more files in changeset.
Unify BuildOperationExecutor and BuildOperationProcessor APIs

This introduces the following `BuildOperationExecutor`

interface (as outlined in gradle/gradle#1676):

void run(RunnableBuildOperation buildOperation);

<T> T call(CallableBuildOperation<T> buildOperation);

<O extends RunnableBuildOperation> void runAll(

Action<BuildOperationQueue<O>> schedulingAction);

<O extends BuildOperation> void runAll(

BuildOperationWorker<O> worker,

Action<BuildOperationQueue<O>> schedulingAction);

To accomplish this, the following changes were performed:

- Various representation of build operations have been merged into

1) BuildOperation (with sub-interfaces)

-> declare and describe a build operation

2) BuildOperationDescriptor (BuildOperationDescriptor.Builder)

-> describe a build operation

3) BuildOperationState

-> represents a running build operation, with run state, start time,

parent relationship information, and description

- The DefaultBuildOperationExecutor and DefaultBuildOperationProcessor

implementations have been merged in DefaultBuildOperationExecutor,

which is now build session scoped.

    • -0
    • +72
    ./groovy/org/gradle/internal/operations/BuildOperationExecutorParallelExecutionIntegrationTest.groovy
  1. … 179 more files in changeset.