Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Set log level even if logging system doesn't need to be installed

Revert "Deactivate log level propagation to java.util.Logging for now"

This reverts commit 9aba91121c2a88d158ac8d60ac692ece78a749f7.

  1. … 1 more file in changeset.
Imports

  1. … 17 more files in changeset.
Imports

  1. … 17 more files in changeset.
Extract anonymous classes to static inner classes

  1. … 145 more files in changeset.
Extract anonymous classes to static inner classes

  1. … 145 more files in changeset.
Extract anonymous classes to static inner classes

  1. … 145 more files in changeset.
Extract anonymous classes to static inner classes

  1. … 145 more files in changeset.
Extract anonymous classes to static inner classes

  1. … 146 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 901 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 901 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 889 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 896 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 901 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 901 more files in changeset.
Add missing @Override to all modules

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

  1. … 1005 more files in changeset.
Add missing @Override to all modules

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

  1. … 999 more files in changeset.
Properly restore System.out and System.err after running a Gradle build in-process.

  1. … 4 more files in changeset.
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.

  1. … 50 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.
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.

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

With javax.annotation.Nullable.

  1. … 460 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.
Use max worker count for build progress labels (#1554)

Break handling of --parallel and --max-workers CLI

out of StartParameter and use it in the CommandLineConverter.

Set the max number of WIP lines through the GradleLauncher and

thread through to the Console configuration.

  1. … 25 more files in changeset.
Moved `Clock` and `TimeProvider` into a separate package

This commit reverts recent changes to the API of

`org.gradle.util.Clock`, and instead deprecates the existing type

replacing with a new internal type. This was done because the

`ExtractDslMetaDataTask` uses this type for timing, and external plugins may have copied this pattern.

`org.gradle.util.Clock` is now deprecated.

  1. … 101 more files in changeset.
Deactivate log level propagation to java.util.Logging for now

Currently, integration tests from in LoggingIntegrationTest and

JavaUtilLoggingSystemIntegrationTest are flaky. Before we know if it

only concerns tests (and how to fix those) I am restoring the original

behaviour of always using the min level FINE. (Keeping the structural

improvements to the logging code.)

+review REVIEW-6255

  1. … 1 more file in changeset.
Remove duplicated test and add unit tests

  1. … 2 more files in changeset.
Reinstated the contract for `LoggingManagerInternal.captureSystemSources()` and `LoggingServiceRegistry.newEmbeddableLogging()`, so that JUL is not touched until `captureSystemSources()` is called.

Reworked the internals to separate the log level for a particular logging system from whether or not the logging system should be generating events or now.

  1. … 14 more files in changeset.
Fix mapping for log level INFO

+review REVIEW-6255