Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Polish PlayCoffeeScriptCompile and TaskGeneratedSingle*Report tasks

Remove now unnecessary noop overridden setters

Only download metadata in parallel

This commit builds on top of the parallel dependency resolution, but limits it to parallel download of metadata. It introduces

an API to determine if the network is effectively going to be hit, in which case edges are added to the queue of work to be

done in parallel. If not (locally available), everything is done serially. This is done because of important contention on

the global lock coordination service lock, which kills performance.

Log timestamp of `log` invocation

Upgrade Groovy to 2.4.11-SNAPSHOT

We need a nightly released with a 2.4.11-SNAPSHOT, because this includes fixes for two important bugs that prevent build caching to work properly in a shared environment. Once a nightly is out we'll be reverting back to using 2.4.10.

+review REVIEW-6505

Revert "Upgrade core Groovy to 2.4.11-SNAPSHOT"

This reverts commit 5f7d951ea97fd7cb1b496df26352c1ffc9408077.

+review REVIEW-6505

Make performance tests stricter

Rebaseline performance tests

The "first use" case is slower because we do more validation of task classes.

The exclude rule merging case is slower because parallel resolution added some

overhead in the case where there is nothing to download. We have improvements

lined up for that, so this rebaselining is just to keep the build from failing

until we merge the fixes.

Use lazy IDE artifacts instead of deferred registration

The 'name' attribute of an IDE artifacts can depend on user configuration.

For this reason, we were deferring the registration of these artifacts until

after the project was evaluated.

This change simplifies things by registering the artifact eagerly, but

having the artifact determine the module name lazily.

Upgrade core Groovy to 2.4.11-SNAPSHOT

This is to test the fixes for:



Other Groovy dependencies are left at 2.4.10 until 2.4.11 GA is released.

+review REVIEW-6505

Ensure reproducible order of task property validation messages

+review REVIEW-6501

Fix random order of validation messages in tests

+review REVIEW-6501

Mention stricter task property validation in release notes

+review REVIEW-6501

    • -0
    • +12
Fix property serializability

+review REVIEW-6501

Fix GenerateProjectSchema UP-TO-DATE behavior

By declaring its inputs

Fix regression with `org.gradle.parallel` property (#1828)

* Fix regression with org.gradle.parallel property

Issue: gradle/gradle#1827

* Convert unit test to integration test

* Add back test case for org.gradle.parallel=false

* Fix parallel integration test

* Fix parallel integration test

Configuration accessors for convention and configuration return Unit

Make it explicit so Dokka doesn’t have to infer it

Generated configuration accessor for conventions returns Unit

For consistency with generated accessors for extensions

Use ready queue to separate ready tasks and blocked tasks

Fix newly detected issues with task properties

- CompileGroovy.groovyOptions.configurationScript now ignores the file path

- CompileGroovy.options.sourcepath is now a proper file collection with relative paths

- Native compile tasks track their absolute include paths as Strings (and ignore the actual contents as before)

- ScalaCompile.scalaOptions.incrementalOptions.analysisFile is now ignored

+review REVIEW-6501

Favor Any? over * in CopySpec extensions

Add more task property validations

- conflicting property types are declared

- same annotation is used on both field and method

- missing @PathSensitive annotation for cacheable task

- @Input used on File or FileCollection property

+review REVIEW-6501

Add more task property validations

- conflicting property types are declared

- same annotation is used on both field and method

- missing @PathSensitive annotation for cacheable task

- @Input used on File or FileCollection property

+review REVIEW-6501

Reintroduce performance improvements for task plan

Revert "Make project lock map thread safe" Revert "Move task dependency check after project lock" Revert "Cache projectlocks in the task execution plan" Revert "Cache task dependency complete status"

This reverts commit ac2b23ef8d5840aa1141a6df2849d159f9da73c3.

This reverts commit 484cbc40e414991a8d11dfc9d42891e5f3ccc103.

This reverts commit 5bc908876103b56e0363424841f6a44e1b5061a0.

This reverts commit 76e6e9ebf38d502de4eb57d94559b779d541baa9.

Fix Java component publishing

When we introduced the `java-library` plugin, we made sure

the published POM reflects what a downstream project in the

same build would see: `api` dependencies are exposed, `implementation`

dependencies are hidden. The legacy `compile`/`runtime` dependencies

are exposed as well for backwards compatibility.

We forgot to adjust the tests for the existing `java` plugin,

leading to a confusing difference in behavior. The `java` plugin

was still hiding the legacy `compile` and `runtime` dependencies from

consumers. This was due to a bug in the implementation of `JavaLibrary`,

which was looking for the `api` configuration instead of the `apiElements`


    • -0
    • +5
  1. … 10 more files in changeset.
Assign build operation ids to workers through requests

A worker currently works on only one build operation at a time,

therefore we can maintain the current build operation by

- separating operation ids used for build operations from those

used for progress logging

- Registering current operation id from build operation executor

- Getting that operation id and storing it in Request to worker

- Setting current operation in worker's local operation registry

upon receipt of the request (now with operation id)

Issue: #1816

Fix performance test

+review REVIEW-6503

Add performance tests to verification group so they show up in tasks

Deduplicate IDE modules based on available projects

Instead of de-duplication based on post-processing the configured

IDE module names, de-duplication is now done for the default IDE

module names, based on the set of available projects. This results

in slightly more predictable behaviour, since the default name of

a module is not dependent on which projects have the IDE plugin


In addition, we now _always_ honour the user-configured IDE module

name, even if this will result in a duplicate name.

Add more test coverage for IDE deduplication