services

Remove synthetic accessors for internal private symbol references

Add missing @Override to all modules

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

Change the tooling API provider to route logging to the client stdout and stderr streams in a similar way to the command-line client.

When not producing rich output the tooling API writes errors to the stderr stream (same as when the command-line client is not run from a console), and when producing rich output the errors are written to the stdout stream (same as when the command-line client is run from a console).

Introduce LoggingServiceRegistry.NO_OP to remove duplication

Change the allocation of progress operation ids so that it is likely that the progress operation id and build operation id of a given start event are the same, and take advantage of this to avoid serializing the build operation id and parent build operation id when they are same as the corresponding progress operation id.

A later change could potentially merge these two separate ids and avoid the cost of tracking two separate, but almost always correlated, values.

Make OutputEventRenderer asynchronous

Simplify ConsoleAttachment so that it always carries the console metadata with it

Change plain console to join stdout/stderr only when console is attached

Write the build failure to stderr when using the plain console, so that the plain console behaviour is a somewhat backwards compatible wrt error reporting.

Allow `StandardOutputListener` logging destinations to be added only from inside a build, and avoid setting up the pipeline that supports this in places where builds will not run, such as the client (except when --no-daemon), worker processes or tapi provider (except when in embedded mode).

Simplify the API to attach different kinds of consoles and remove some complexity from the test fixtures and TAPI provider.

Guarantee that logs are flushed before reporting build status

Merge stdout/stderr chains and introduce a throttled plain console

Avoid deadlock between output event renderer and listener manager (#4661)

Previously, the output event listener that forward build op notifications was downstream of the output event renderer, which has its own lock. It was possible to deadlock between this lock and the global listener manager lock.

Now, the build op notification forwarder is a peer of the renderer, so is not notified under its lock.

Emit build operation progress events for logging output (#4537)

* Tweak BuildOperationListener#progress api

* Use build operation id to reference progress

* Add workaround for tracing log output via build operation progress for composite builds

* Replace some Object typing of operation identifiers with OperationIdentifier.

* Associate all progress logging with the current build operation.

* Update logic to accommodate for all progress events now having build operation IDs.

* Don't allow ProgressStartEvent.buildOperationCategory to be null.

** Default it to uncategorized.

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.

Simplify time handling internally and for build scans (#2857)

* Don't make TimeProvider Serializable.

This isn't safe and generally doesn't make sense.

* Extract and promote the concept of a build timer.

This was previously not well defined and being overlaid with the concept of when a user/tool requested something, which is not always the same thing.

* Pare down the deprecated org.gradle.util.Clock down to the minimum required.

Internal usage is replaced by a `getStartTime()` directly on BuildRequestContext.

What is left is only kept for backwards compatibility with scans.

* Rename TimeProvider to Clock.

* Move BuildExecutionTimer out of baseServices into core, and into a better package.

* Remove unused.

* Simplify the time package by merging types.

* Prevent the client's build started timestamp from being later than when the provider received the build request.

* Provide a dedicated mechanism for conveying the build start time to build scans.

* Consolidate the ways of formatting durations.

Make observed wall clock timestamps monotonic and provide clock view for scans plugin (#2806)

Make Gradle's clock suitable for use by build scans.

- Guarantee that timestamps issued by the build runtime are monotonic

- Provide a dedicated view of the clock for build scans, allowing the name/shape of the internal clock to change later

Introduce a nanoTime-backed TimeProvider implementation

- Use this TimeProvider for most services

Remove unnecessary max worker count logic from logging (#2563)

The --max-worker setting no longer has impact on logging or

console display, so remove logic that propagates its value

through logging.

Issue: #2411

Set default log level back to LIFECYCLE (#2015)

Refactor org.gradle.logging.level property tests (#1964)

* Split out logging tests

* Clean up tests, ignore failing test

* Code review changes