Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Log name of task experiencing problems with (un)packing its results

Previously we logged the name of the offending property, but not the task name.

Log the task when there’s an uncaught exception during execution

Previously if there was an exception during task execution, we didn’t always log the task name with the exception.

Increase memory for the daemon

The Gradle build needs more than 1G for some more demanding tasks

like a parallel `quickCheck`.

This change also reduces the client VM memory to something reasonable.

It was set to 2G before because we were running the build in the client

VM on CI. Instead we will now be forking single-use daemons on CI, which

only adds ~500ms per build and interoperates better with the memory being

defined in gradle.properties.

    • -1
    • +1
    /gradle/wrapper/gradle-wrapper.properties
Polish release notes

+review REVIEW-6541

    • -2
    • +2
    /subprojects/docs/src/docs/release/notes.md
Rename org.gradle{.api.resources -> }.normalization

+review REVIEW-6540

  1. … 35 more files in changeset.
Annotate more non public APIs used by the build scan plugin and add clarifying comments.

Find loaded packages in a Java 9 compatible way

We can use reflection to look up the Java 9 friendly public method

`getDefinedPackages()`. If it doesn't exist, then we must not be

running on Java 9, and we should expect to be able to access the

protected `getPacakges` method since that isn't outlawed before Java

9.

Started reworking `ExternalResourceRepository` so that no network request spans more than one method call on `ExternalResourceRepository` or `ExternalResource`.

This is work in progress and this change leaves `ExternalResourceRepository` in an intermediate state between the old and new behaviours. A subsequent change will remove the old behaviours entirely.

The semantics of the `ExternalResourceDownloadBuildOperationType` have changed in several ways:

- The build operation wraps the entire network request, rather than the "download" portion of the request.

- The build operation events are fired regardless of whether the network request was successful or not.

- No content type or content length are included in the operation's detail.

This build operation type is yet to be refactored or documented to reflect these changes.

Allow script plugins to be applied via the plugins DSL

Remote URLs are also supported:

```

plugins {

script "path/to/other.gradle"

script "https://example.com/another.gradle"

}

```

Local file paths are expressed as relative from the requesting script.

Constrain plugins {} block api to distinguish binary and script

plugin requests by both strongly modeled types and ad-hoc groovy parsing

of the plugins block. This pave the way for proper support of the

plugins {} block with the Gradle Kotlin DSL.

Implement ScriptPlugin PluginResolver by generating a synthetic

"imperative" Plugin class that loads and applies the script plugin when

applied.

This synthetic generated loader class and the script plugins are loaded

into the buildSrc classloader scope.

Only Project targets are supported.

`apply false` is not supported.

  1. … 50 more files in changeset.
Merge pull request #2119 from gradle/rbo/release/gradle-script-kotlin-0.9.0

Upgrade gradle-script-kotlin {0.8.0 => 0.9.0}

Pushed usage of `ExternalResourceName` instead of `URI` to represent a remote resource closer to the origin.

  1. … 8 more files in changeset.
Stop testing with Java 9 until we fix Gradle (#2115)

This change removes our test coverage for Java 9 support. We are

currently broken with the latest ea releases of the Java 9 JVM, so we

shouldn't attempt to run our tests using Java 9.

We will reenable this when we have fixed the issues.

Update Configuration Documentation (#1928)

This change documents how configurations actually work with the Java

Plugin and Java Library Plugin, and encourages build authors to use the

Java Library Plugin for most java projects.

We need a section which talks about the different ways plugins might

use configurations so that we can explain why we are getting rid of

some configurations which used to do double-duty on this front.

This is an attempt to encourage people to start migrating to the new

Java Library Plugin and the configurations defined therein.

Fixes #1854

Polish `DefaultPluginRequestApplicator`

- Compose methods

- Favour static imports wherever they improve flow

Polish `PluginId`

- Fix typo

- Remove spurious empty line

Polish `PluginRequest`

Add missing javadoc marker.

Trim whitespace at the end of task groups (#2113)

Reduce visibility of getCandidateClassFiles()

Add build tree scope services to comment on settings scope

Avoid flakiness caused by a given phase not being rendered because it completes quickly

Merge pull request #2096 from gradle/ew/logging/better-continuous-ux

Better continuous build console UX

Format the project path in display names for `ProjectComponentIdentifier` in the same way that the fully qualified project path is formatted elsewhere.

This logic is still duplicated in `DefaultProjectComponentIdentifier`, and instead the value already calculated for the project should be reused instead of recalculated.

Fix minor issues of javaPlugin.adoc

- some escaping of `*`

- added newlines to make lists work correctly

Merge remote-tracking branch 'origin/release'

* origin/release:

Add abstract base class for PluginServiceRegistry implementations

Convert some wordy daemon logs to DEBUG from INFO (#2097)

Add some basic functional tests asserting task output grouping - PART II (#2095)

Fix jar snapshot cache not keeping jars in order

Revert "Revert incremental compiler fixes because of a performance regression"

Tag builds which failed to upload to build cache

Gather custom scan data for buildSrc

Revert incremental compiler fixes because of a performance regression

Rename ResourceNormalization to InputNormalization

Use BuildOperationListener for buildScan custom values

Update wrapper to latest release nightly

Fix jar hashes ordering being lost

Revert "Revert "Recompile everything whenever jars are reordered""

Some test fixes for changes to display names.

Fixed int tests for changes to dependency resolution build operation display names.

Some tweaks to build operation display names, to reflect some human consumable identify of the operation rather than a statement of what Gradle happened to be doing when the operation started.

Tweaked `AbstractConsoleFunctionalSpec` to better deal with the presence of the work in progress section.

Added some test coverage to show that the fully qualified paths for various things are used in error messages when dependency resolution goes wrong in a composite build or a `buildSrc` build.

Ensure that progress information is shown in the 'work in progress' console area when resolving the dependency graph for a configuration and when resolving the files/artifacts for a configuration.

Show 4 'work in progress' lines on the console when the screen size is not known (eg when running from a functional test).

Add abstract base class for PluginServiceRegistry implementations

Convert some wordy daemon logs to DEBUG from INFO (#2097)

Add some basic functional tests asserting task output grouping - PART II (#2095)

* Add some basic functional tests asserting task output grouping

* First round of review feedback

* Split parsing logic into testable fixture

* Fix problem when progress bar is updated between tasks

* Convert ExecOutput test to use test fixture

* Make test fixtures more user friendly

* Fix quickCheck

* Fix flaky tests

* Another attempt at ignoring progress bar

* Replace control characters in task output

Fix jar snapshot cache not keeping jars in order

Remove SettingScopePluginServiceRegistry and GradleUserHomeScopePluginServices

The register methods are moved to PluginServiceRegistry

Periodically forward output of long running task