gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Address more review feedback

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

Mostly adding more Javadoc and throwing exceptions when a daemon

can't be notified.

    • -2
    • +2
    ./launcher/cli/BuildActionsFactory.java
    • -3
    • +7
    ./launcher/daemon/client/DaemonClientFactory.java
  1. … 3 more files in changeset.
Do not notify busy daemons

  1. … 4 more files in changeset.
Consistently use changedPaths

and `notifyDaemonAboutChangedPaths`

    • -80
    • +0
    ./launcher/daemon/client/DaemonFileSystemChangesNotificationClient.java
    • -0
    • +80
    ./launcher/daemon/client/NotifyDaemonAboutChangedPathsClient.java
    • -0
    • +33
    ./launcher/daemon/protocol/InvalidateVirtualFileSystem.java
    • -0
    • +49
    ./launcher/daemon/server/api/HandleInvalidateVirtualFileSystem.java
  1. … 13 more files in changeset.
Address some review feedback

  1. … 2 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
    • +80
    ./launcher/daemon/client/DaemonFileSystemChangesNotificationClient.java
  1. … 15 more files in changeset.
Move some classes out of 'launcher' project to 'buildEvents'.

  1. … 111 more files in changeset.
Add dependency verification mode

This commit introduces a selection of the dependency verification

mode. There are 3 different modes: strict (default), lenient and

off.

The lenient mode has been added because dogfooding the feature showed

it could be painful to udpate the dependency verification

metadata file without such an option: often we want to diagnose

why a dependency is here, but as soon as the dependency

verification file is present, verification is active and immediately

fails the build.

This effectively prevents from using the usual tooling to check

where a dependency comes from. The workaround was to temporarily

rename the file, run the build, then rename again, which was tedious.

So, instead of adding a mode where verification would be totally

ignored, this commit introduces a mode where the errors are turned

into warnings. This doesn't totally silence the problems, which

makes them more visible to the developer.

The "off" mode is for use cases where users prefer not to deal

with upgrades locally, but want to see verification happening

on CI only.

    • -0
    • +3
    ./launcher/cli/action/BuildActionSerializer.java
  1. … 8 more files in changeset.
Introduce an API to allow task metrics to be collected by build logic.

  1. … 8 more files in changeset.
Log more about the event being dispatched to the client

Make selection of checksum algorithms mandatory

Instead of using a default list, the user has to choose

what checksums to generate when bootstrapping the dependency

verification file.

This is done because it will have an impact when checking

the dependencies: all checksums will be verified.

    • -2
    • +5
    ./launcher/cli/action/BuildActionSerializer.java
  1. … 7 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +2
    ./launcher/cli/action/BuildActionSerializer.java
  1. … 32 more files in changeset.
Use default values for TAPI provider interfaces

  1. … 2 more files in changeset.
Add new methods to execute tests in a single task

  1. … 5 more files in changeset.
Prototype new TestLauncher.withTests() API method

  1. … 5 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

  1. … 61 more files in changeset.
Revert "Merge branch 'release'"

This reverts commit c7fdc455dcb9a8016af0ae9bc8b4c43fde1e2d06, reversing

changes made to 9f70d52b74dbc8c71381781b6c155474031b3cf8.

The changes need a wrapper as there are API changes. Reverting for now.

  1. … 61 more files in changeset.
Reduce the amount of logging that is periodically emitted by an idle daemon

  1. … 2 more files in changeset.
Use single event instead of start-finish pair to publish test output

  1. … 12 more files in changeset.
Fix regression when deprecating search upward APIs

    • -6
    • +4
    ./launcher/cli/action/BuildActionSerializer.java
  1. … 11 more files in changeset.
Use enum for Destination

  1. … 8 more files in changeset.
Align naming

  1. … 5 more files in changeset.
Assign test output events to new operation type

  1. … 3 more files in changeset.
Put test output into result object

  1. … 14 more files in changeset.
Warn about deprecation of search upwards and similar APIs

    • -4
    • +6
    ./launcher/cli/action/BuildActionSerializer.java
  1. … 8 more files in changeset.
Remove test output from test events

  1. … 21 more files in changeset.
Primitive implementation for TestOutputEvents

  1. … 16 more files in changeset.
Run all tasks read from the instant execution cache in parallel. Each of the tasks is isolated from the project state and so can run in parallel.

  1. … 5 more files in changeset.
Remove unnecessary field

Add output and error to test failures

  1. … 6 more files in changeset.