Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Attempt to make OutputScrapingExecutionResult more tolerant of interleaved task output

Moved core included-build types into separate packages

- org.gradle.initialization.[Configurable]IncludedBuild -> org.gradle.includedbuild.[Configurable]IncludedBuild

- org.gradle.initialization.includedbuild.* -> org.gradle.includedbuild.internal.*

Better names

  1. … 49 more files in changeset.
Add minimal `buildSrc` sample project

    • -0
    • +13
    /samples/project-with-buildSrc/README.md
    • -0
    • +169
    /samples/project-with-buildSrc/gradlew
    • -0
    • +84
    /samples/project-with-buildSrc/gradlew.bat
    • -0
    • +0
    /samples/project-with-buildSrc/settings.gradle
Renamed `TaskDependencyGraph` -> `TaskInfoFactory`

Implement exponential backoff for cross-process file locking

Avoid creating unused output streams

Merge branch 'release'

Merge pull request #2230 from gradle/sw/gradle-build/build-cache-coverage-phase

Add jvm vendor as an input for test tasks

Fix missing @since and @Incubating annotation

Use JavaInstallationProbe to detect Java vendor

Make FS case sensitivity check lazy

Move IDE TAPI model integration tests from :toolingApi to :ide

  1. … 81 more files in changeset.
Move skipping TAPI tests depending on executer to ToolingApiSpecification

Fix minor inefficiencies in CLI client startup

ImmutableSet is faster than HashSet, for-loop is faster than

"functional" programming with Guava.

Enable caching for coverage builds

+review REVIEW-6544

  1. … 59 more files in changeset.
Remove double date conversion in GradleVersion

We were putting the build time into the build receipt in

a different format than what we want in GradleVersion, which

is the only client of that information. Instead we now compute

the right value when we build the distribution and pass it verbatim

into GradleVersion.

Avoid String.format, it's inefficient

Remove unused `-PtimestampedVersion`

  1. … 87 more files in changeset.
Make JvmOptions more efficient

The bootstrap classpath is often empty, so we optimize for that scenario

by making the field lazy.

Add Java vendor as an input for compile and test tasks

In the coverage phase we use different Java vendors.

Therefore, we need to track the vendor if we want to use the build cache.

Use non-caching pattern spec factory in CLI

The caching pattern spec factory is expensive to create (due

to instantiating its caches) and we don't need it in the CLI

process if the actual build is run by the daemon.

Move constants to classes using them

Initializing a GregorianCalendar is expensive and GUtil is used

in the CLI client, so we want to keep its init time small.

Split global services for faster CLI startup

The CLI, Daemon and Tooling API all share certain global services.

But when the CLI is just forwarding the build request to the daemon

(which is the default), we don't need most of these services. This

change splits the global services into a basic part (that the CLI

always needs) and an extended part (that it only needs in --no-daemon

mode). This greatly speeds up startup for the default case, because we

do less class loading, less instantiation and less service lookups.

Ensure exact task name is supplied for included build task reference

We were incidentally permitting the shorthand notation when creating an

included build task reference. With recent changes, this no longer works

because the task requested doesn't match the task executed.

This commit removes the ability to provide a partially-matched task

name for an included build task reference.

This also fixes an integration test that accidentally relied on partial-name

matching, thus exposing the changed behaviour.

Fix integration test for removal of delegate tasks in composite build

Wait for included build thread to complete when stopping controller

Add test that demonstrates multiple executions of included build

Tasks for an included build are preemptively scheduled when they

are discovered while building the task graph. However certain dependencies

(such as compileOnly) may be discovered after the build has commenced.

In these cases, the included build will be invoked again, resulting in

multiple executions of the same included build. This test demonstrates

this scenario.

Use a listener to record task results for included builds

Waiting the included build execution to complete had a number of issues:

- It was not possible to assign the correct failure to a particular task

- Race condition setting the 'complete' flag for a task in time for

the graph requesting this status

Using a listener to track the status of the included build execution

eliminates these issues.

Used shared instance of IncludedBuildTaskGraph in CompositeBuildIdeProjectResolver

Merge branch 'release'