Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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'

Fail (for now) if max-workers < build count for composite

Polish `ForkingGradleHandle`

- Compose methods

- DRY

- Reduce accessibility of methods

- Replace `toPlatformLineSeparators("\n")` by `getPlatformLineSeparator()`

- Avoid excessive map instantiation by caching `execHandle.getEnvironment()`

Polish `ExternalResourceResolver`

- Compose methods

- DRY

Integrate the prepare test into the regular integ test suite and resolve more configurations

Make all integration tests depend on the prepare phase, not only the parallel version

In other words, even `integTest` can have test classes running concurrently, because of `maxParallleForks`.

Pre-populate the repository for Play! tests

This commit introduces a new task, `integTestPrepare`, which is executed before any other Play! integration test

and will populate the Gradle cache found in the integration test home directory with dependencies used by the

integration tests. This should prevent some flakiness in those tests, which tend to timeout because they all try

to download the Scala compiler and its family. While it's in general not an issue, the problem is that the

collection of artifacts to be download is quite large, so cross-process locking may reach the 60s timeout. To

prevent this from happening, we forcefully execute a dummy test during the `integTestPrepare` execution, which

will trigger downloading of dependencies. This test is alone, and will be executed serially before the integration

tests run concurrently in `parallelIntegTest`.

Replace /build-cache/ with /cache/ in example URL

For GE the default url is ``<GE url>/cache`.

We should be consistent in our examples with the URL.

Merge branch 'so-stable-performance-tests' into release

Use GStrings in Test

+review REVIEW-6543

Cleanup BuildStatusRendererFunctionalTest

Remove spurious printlns

Fix BuildStatusRendererFunctionalTest flakiness

The test was looking for EXECUTING on buildFinished.

This commit change this to actual execution phase.

TeamCity change in 'Gradle :: Branches :: Coverage Phase :: Linux Coverage' project: 'AdHoc Task Execution - Linux' build configuration was moved to 'Gradle :: Branches :: Commit Phase :: Linux commit' project

TeamCity change in 'Gradle :: Branches :: Coverage Phase :: Linux Coverage' project: requirements of 'AdHoc Task Execution - Linux' build configuration were updated

TeamCity change in 'Gradle :: Branches :: Coverage Phase :: Linux Coverage' project: copy of 'AdHoc Task Execution - Windows' build configuration was created

Merge branch 'so-more-sensitive-perf-tests' into so-stable-performance-tests

Add a Java configuration time performance test

This makes it easier to track down configuration

time problems vs. up-to-date checking problems.

Rebaseline all performance tests

This is to make sure that we don't regress against the

recent improvements in performance again until 4.0 GA is out.

Once GA is out, all these baselines can be removed again, as testing

against the latest GA is the default.

  1. … 8 more files in changeset.
Make Maven always run 'clean' in performance tests

Maven has no working incremental build support, so we

should be measuring clean builds instead, which is what

Maven users are always using.