Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Revert "stumbled upon unused field; removed"

This reverts commit 70f47b931b68939c826a21ae7d2d9f7a90431a81.

- breaks 'com.bmuschko.tomcat' plugin

Add missing license headers

Fix :plugins publication maven coordinates

stumbled upon unused field; removed

Changed the C++ executable and library plugins to use the new types to express task inputs and outputs to simplify the task wiring.

    • -2
    • +2
    • -2
    • +2
    • -3
    • +3
Added APIs that allow a specific task output directory or output file to be wired in as an input for another task, in a way that allows the task dependencies to be inferred and that deals with later changes to the configured locations of those outputs. This is intended to be a more robust, performant and descriptive alternative to using `File` property types and calls to `Task.dependsOn`

Specifically, added factory methods on `DefaultTask` to allow a task implementation class to create `DirectoryVar` instances that represent an output directory, and `RegularFileVar` instances that represent an output file or directory. When used as an output directory or file property, these instances carry dependency information about the producing task. When used as an input file property, the producing task is tracked as a dependency of the consuming task.

Similar support for input files is done using `ConfigurableFileCollection` and friends, as has been possible for quite a while. There is intentionally no concept of an input directory in these changes. However, it is possible to view a `Directory` or `DirectoryVar` as a `FileTree` which can be wired in as a task input.

Fix issue 2077 - StringIndexOutOfBoundsException on Windows

When there are consecutive \r character are appended on Windows, a

StringIndexOutOfBoundsException will be thrown. The reason is this

scenario is not considered and tested.

Create build operation for GradleBuild execution

Test dependency on non-default artifact in composite build

Simplified the management of build phases in DefaultGradleLauncher

This makes it easier to manage the lifecycle of each included build

in a composite. In addition, buildStarted and buildFinished events

are now fired appropriately for included builds in most cases.

Added a placeholder for the new plugin APIs in release notes.

    • -0
    • +8

Fixed `Project.file()` and `Project.files()` to properly handle `Directory` and `RegularFile`. Also fixed `Project.files()` when presented a `Path` instance. Added some test coverage and updated the Javadocs on `Project`.

Some fixes to the implementations of `Provider.isPresent()` and `getOrNull()` for the various instances created by `ProjectLayout` and related types. Extracted some reusable abstract classes to fix these in as few places as possible.

Make BuildController stoppable and remove a few more uses of GradleLauncher

Use `BuildController` in place of `GradleLauncher` for nested builds

Changed `Directory` so it represents a directory at a fixed location, rather than a directory whose location may or may not be known. Also added `RegularFile` to represent a file at a fixed location, added some `Provider` subtypes that represent some configurable directory or file variable and that provide conveniences for setting their value and deriving other locations relative to their value.

Changed the C++ plugins to use these types.

Adjust code to match project conventions

- Indent function arguments rather than aligning them

- Group imported packages

- Use single line to separate type members (two lines for module members)

Share IntelliJ code style settings

    • -0
    • +19
:plugins publication metadata

:plugins publication metadata

Version :plugins separately

Handle ArmCC version determiner

Mention build cache guide in user guide (#2288)

Dedupe assertions with a list of task names

Merge pull request #2286 from gradle/sg/composite/operations

Nest included build operations under outermost operation

Rework fix for parallel downloads on authenticated repositories

This commit reworks the fix for authenticated repositories to use a queue of `HttpContext` instead of a thread local map.

The rationale for this change is that 2 subsequent requests are not necessarily executed on the same thread. This means that

if request 1 performed authentication, and request 2 is done some time later, but on a different thread, authentication is

going to be done again.

To avoid this, request 1 will ask for a context in a queue. If no context is available, a new one is added. Once the request

is done, the context is added back in the queue, making it availble for subsequent requests to pick up. Request 2 comes and

picks it from the queue, then authentication state can be reused.

This means that at most, we can re-authenticate as many times as there are concurrent requests. But in practice, it is likely

that we're going to reuse shared context.

This commit also adds an integration test proving that parallel downloads work with authenticated repositories.

Ignore flaky test for now

Mention build cache guide in release notes

    • -1
    • +1
Fix synchronization in `HttpClientHelper`

This commit fixes the synchronization in `HttpClientHelper` which prevented parallel downloads from happening in case

of an authenticated repository. To fix it, the helper now maintains a map of thread to http context, as recommended

by the HttpClient team. We don't use the JDK thread-local map because we need to clear the contexts once we close

the helper, in order to avoid leaking memory.