Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Consistently use changedPaths

and `notifyDaemonAboutChangedPaths`

    • -33
    • +0
    ./InvalidateFileSystemLocations.java
    • -0
    • +33
    ./InvalidateVirtualFileSystem.java
  1. … 21 more files in changeset.
Allow notifying about FS changes via the TAPI

This PR adds a new method to `ProjectConnection`, which sends a message

to all daemons and causes them to invalidate some part of the

retained file system state.

    • -0
    • +33
    ./InvalidateFileSystemLocations.java
  1. … 22 more files in changeset.
Allow notifying about FS changes via the TAPI

This PR adds a new method to `ProjectConnection`, which sends a message

to all daemons and causes them to invalidate some part of the

retained file system state.

    • -0
    • +33
    ./InvalidateFileSystemLocations.java
  1. … 22 more files in changeset.
Apply `Explicit type can be replaced with <>` inspection the whole project

  1. … 909 more files in changeset.
Simplify launcher project structure

  1. … 561 more files in changeset.
Simplify launcher project structure

  1. … 561 more files in changeset.
Simplify launcher project structure

  1. … 559 more files in changeset.
Simplify launcher project structure

    • -0
    • +371
    ./DaemonMessageSerializer.java
    • -0
    • +32
    ./DaemonUnavailable.java
    • -0
    • +30
    ./OutputMessage.java
  1. … 544 more files in changeset.
Simplify launcher project structure

  1. … 561 more files in changeset.
Simplify launcher project structure

  1. … 561 more files in changeset.
Split :launcher into :launcher, :launcherBootstrap and :launcherStartup

in order to isolate Java 6 stuff

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

  1. … 530 more files in changeset.
Split :launcher into :launcher, :launcherBootstrap and :launcherStartup

in order to isolate Java 6 stuff

Let split launcher projects code be shipped in a fat jar

for backwards compatibility

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

  1. … 534 more files in changeset.
Split :launcher into :launcher, :launcherBootstrap and :launcherStartup

in order to isolate Java 6 stuff

Let split launcher projects code be shipped in a fat jar

for backwards compatibility

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

  1. … 534 more files in changeset.
Remove some usages of Java serialization in sending the build result to the client. The `BuildActionResult` and `SerializedPayload` are serialized much more efficiently in the response to the client, particularly for 'build successful' results when invoked from the command-line, but also for results when invoked from the tooling API.

Previously, these types were not used in the command-line case so this improvement is really only returning to existing behaviour for these builds.

  1. … 4 more files in changeset.
Move the 'interactive' flag that is passed from the client to daemon so that it lives in only one place. The flag is still on `StartParameter` but is unused and should later be deprecated and removed.

  1. … 18 more files in changeset.
Change the user prompt infrastructure to give the user some feedback when they enter a value that isn't valid for the question. Add some test coverage for user prompting.

  1. … 24 more files in changeset.
Remove remaining Java serialization from the initial build request message sent from the client to the daemon. There is now no Java serialization used between the client and daemon when running builds from the command-line. There is still some when using the Tooling API.

  1. … 24 more files in changeset.
Use Java serialization for less of the initial build request message that travels from the client to daemon.

  1. … 4 more files in changeset.
Don't use Java serialization for the messages between the client and daemon that happen during a command-line build. Some Java serialization is used in a couple of places for the payload of these messages and for some of the messages that happen during a TAPI operation.

  1. … 2 more files in changeset.
Don't use Java serialization for the initial 'build' command sent from the client to daemon. Some of the pieces of the build command (e.g. the `StartParameter`) are still serialized using Java serialization.

  1. … 13 more files in changeset.
Capture user input via internal API (#3007)

  1. … 28 more files in changeset.
Address review feedback

- use DaemonServerConfiguration to pass information further down

- remove BuildAndStop command

- change naming to use singleUse

+review REVIEW-6567

  1. … 14 more files in changeset.
Properly serialize LogGroupHeaderEvents

  1. … 4 more files in changeset.
Replace usages of org.gradle.api.Nullable

With javax.annotation.Nullable.

  1. … 460 more files in changeset.
Make progress event serialization more compact

Use a single byte to indicate nullness of all optional fields

instead of writing one byte for each of them.

  1. … 2 more files in changeset.
Rename progress.BuildOperationType to BuildOperationCategory

  1. … 16 more files in changeset.
Group logs by project and task

Introduces a BuildOperationType enum and adds it to the

default BuildOperationDescriptor. Passes this information

to the logging infrastructure through the BuildOperationExecutor.

All BuildOperations now have a ProgressLogger. This allows

progress logging to maintain a heirarchy of build operations,

otherwise we would not be able to group many log events.

ProgressStartEvents are given additional information in a

compact form to allow a tree of build operations to be

maintained and their operation types associated. This allows us

to associate log events who aren't fired by progress logging to

still be grouped.

A LogGroupingOutputEventListener uses these build operation

types and the build operation heirarchy to buffer and output

logs related to tasks and project configurations.

Issue: #1818

  1. … 30 more files in changeset.
Add build operation types to log events

This will allow OutputEventListeners to react to output events

from different types of operations differently.

Remove BuildProgressLogger and move progress bar logic and

rendering to BuildStatusRenderer where it belongs.

Issue: #1818

  1. … 46 more files in changeset.
Revert some logging changes

- Move OperationIdentifier back to logging and use Objects for

BuildOperation ids

- Remove log event builders and use plain constructors to avoid too

much garbage

  1. … 54 more files in changeset.
Mark log events with their associated build operation id

Use BuildOperationIdentifierRegistry in all of the places where

we generate renderable output events to set build operation id.

Serialize Operation identifiers coming from forked processes.

Use Builder pattern for constructing renderable output events to

avoid an explosion of constructors while maintaining forward

compatibility. (0 uses of StyledTextOutputEvent in non-forked

repos, so removed those constructors, they're internal anyway)

Reuse BuildOperation ids through progress logging where we

can.

Issue: #1611

  1. … 55 more files in changeset.