Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Extract logic to find all generator tasks

And fix it to include all project generator tasks.

Extract logic to find all generator tasks

And fix it to include all project generator tasks.

Favour indexer over explicit `get/set` invocation

  1. … 2 more files in changeset.
Polish Kotlin build scripts and plugins

- Favour `KClass` based overloads wherever possible

  1. … 12 more files in changeset.
Merge branch 'master' into wolfs/idea-import/spike

Remove dependency on Java 7 in our build (#6494)

### Context

Currently we need 3 JDKs to build Gradle:

- Java 7 to compile most code

- Our build runs on Java 8

- Java 9 to compile some code using Java 9 API.

Our goal is to use only one JDK. After this PR, we can:

- If running the build on Java 9/10, we can only use a single JDK.

- If running the build on Java 8, we still need an extra JDK to compile some code using Java 9 API. After we migrate all CI builds to Java 9/10, we may completely drop the support for running on Java 8.

However, with https://youtrack.jetbrains.com/issue/IDEA-197550 unsolved, we still can't run Gradle integration tests in IDEA with JDK 10. Everything else would work fine on JDK10.

#### Remove multiple compiler JDKs

Previously, we use different JDKs to compile different subprojects, which made things really complicated. This PR greatly simplify the compiler selection code, after this PR, we only need one single Java9-compatible JDK to compile all code.

#### Refine verification mechanism

Previously, we had verification for:

- If build cache enabled, verify the current build is running on Java 8 because CI is running on Java 8.

- If running some specific tasks (e.g. distribution generation), verify the build/compiler JDK is Oracle JDK.

This PR does the following improvements:

- Since all `Compile` tasks share a common compiler, verify that compiler is Java9-compatible. Oracle JDK is not mandatory.

- If running some specific tasks (e.g. distribution generation), verify the build/compiler JDK is Oracle JDK.

This PR collects these verification into a single plugin, instead of code everywhere previously.

  1. … 14 more files in changeset.
Use resourceDirs for resources

It seems more correct to use resourceDirs for resources.

This reverts commit 8a6406b71dc50c106ce606684fbe15c9371c9086.

  1. … 2 more files in changeset.
Revert "Use resourceDirs for resources"

This reverts commit 3669395ec066fc29fc7eb119e82e0a7de4e640b2.

  1. … 2 more files in changeset.
Use resourceDirs for resources

  1. … 2 more files in changeset.
Move configuration to IdePlugin

  1. … 4 more files in changeset.
Improve performance test (#6122)

In https://github.com/gradle/gradle/pull/5865 we made distributed performance test cacheable, which resulted in https://github.com/gradle/gradle-private/issues/1392 . The issue was that `DistributedPerformanceTest` and `performanceReport` are different tasks, and `performanceReport` task depends on some particular properties set by `DistributedPerformanceTest` at runtime. If `DistributedPerformanceTest` is not executed, `performanceReport` will be disrupted.

This PR merges `performanceReport` task into `PerformanceTest`. After this change, `PerformanceTest`'s inputs are Gradle binary distributions and a series of properties such as `baselines`/`warmups`, etc, and outputs are original outputs plus performance reports. This introduces another bonus - `PerformanceTest` can be cacheable, which means if nothing changes, we don't have to rerun it.

  1. … 3 more files in changeset.
Validate Jdks at execution time (#6335)

So that configuration time can be faster by avoiding to call

JavaInstallationProbe.

  1. … 4 more files in changeset.
Only run Kotlin tests on this branch

Apply int-test-image plugin in PerformanceTestIntegrationTest in buildSrc

for the partialDistribution configuration to exist.

Was previously relying on container string invoke being maybeCreate()

Signed-off-by: Paul Merlin <paul@gradle.com>

Replace string invoke by `register` or `create`

  1. … 8 more files in changeset.
Make environment variable mutation work on Java9+

Mutating the environment requires reflection on the

java.util package, so we need to open that package

up to Gradle. Since Gradle is not modularized, this

means opening it up to the whole classpath. This is

less than desirable, but the only way to restore the

behavior we had on Java 8 and below.

We should start limiting access to environment variables

going forward so users don't depend on arbitrary values.

However, this change allows us to unblock users who are

currently either not using Java 9 or running Gradle in

no-daemon mode, both of which are terrible solutions.

  1. … 11 more files in changeset.
Use external repository mirrors in build (#6094)

We've been bitten by external repository fluctuation for a long time.

This PR makes most of tests use repository mirrors set up by ourselves

via init script and system property.

There're still some tests not switching to mirrors, which would be fixed

in follow-up commits.

  1. … 99 more files in changeset.
Revert to reified syntax

and remove now moved upstream kotlin-dsl extensions

Signed-off-by: Paul Merlin <paul@gradle.com>

  1. … 4 more files in changeset.
Prepare for Kotlin DSL upgrade with Kotlin 1.2.60-eap-44

- Disable ktlint-convention plugin because it can only run against a

single Kotlin version

- Disambiguate `mock<T> { ... }` calls via `name` parameter

(necessary due to the `SamConversionForKotlinFunctions` feature)

- Replace delegated property of type `Any?` by API call

- Replace calls to reified extensions moved upstream by API calls

  1. … 5 more files in changeset.
Favor unambiguous apply() functions over the ambiguous apply {}

`apply {}` is ambiguous due to the `kotlin-stdlib` extension function

with the same name on `Any` that shadows our `apply {}` in some cases.

This commit contains mechanical changes of all apply {} usages, favoring

the unambiguous equivalent functions.

See the discussion in gradle/kotlin-dsl#682 for more details.

Signed-off-by: Paul Merlin <paul@gradle.com>

  1. … 14 more files in changeset.
Update mockito-kotlin to 1.6.0 (#5918)

Update mockito-kotlin to 1.6.0 to support building gradle/gradle on Java 10.

  1. … 1 more file in changeset.
Preliminary support for building Gradle on Java 9 (#5811)

This is a follow-up of https://github.com/gradle/gradle/pull/5749 . #5749 introduced Java 9 compiler but broke IDE import. This PR aims at fixing IDE import. With this PR, we can run `./gradlew idea` and set project SDK to JDK 9 to run integration tests.

The changes are:

- Upgrade javaassist to JDK9-compatible version

- Adds empty implementation to `AnnotationProcessingCompileTask` and `ResourceCleaningCompilationTask`

- Remove support of Java 5 because Java 9 can't generate Java 5 bytecode any more.

- Slightly increased wrapper size limitation because two extra classes are added.

  1. … 21 more files in changeset.
Make DistributedPerformanceTest cacheable (#5865)

Previously, `DistributedPerformanceTest` is non cacheable, which means, even though only a typo is fixed in documentation, the whole time-wasting PerformanceTestCoordinator stage will run for a few hours. This PR fixed this issue.

  1. … 4 more files in changeset.
Support build gradle/gradle on Java 9

This commit fix three issues:

- Upgrade javassist to support Java 9

- Remove limitation of building gradle/gradle on Java 9

- Remove special case for Java 9 compiler since Java 7 compiler is still used

  1. … 2 more files in changeset.
Revert "Use Lookup instead of reflection on Java 9+ (#5749)"

This reverts commit 3db6e256987053171178aa96a0ef46caedc8d1a4.

  1. … 16 more files in changeset.
Revert "Use Lookup instead of reflection on Java 9+ (#5749)"

This reverts commit 3db6e256987053171178aa96a0ef46caedc8d1a4.

This causes IDE import broken.

  1. … 16 more files in changeset.
Use Lookup instead of reflection on Java 9+ (#5749)

In `4.8` we have two `illegal-access` warning on Java 9+. This PR uses Java 9 API to eliminate these warning. However, the consequence is, we need Java 9 compiler to compile the specific subproject `base-servces-java9`.

On Java 9+, `MethodHandles.Lookup` is used to invoke protected methods `ClassLoader.defineClass` and `ClassLoader.getDefinedPackage`.

  1. … 16 more files in changeset.
Use Lookup instead of reflection on Java 9+ (#5749)

In `4.8` we have two `illegal-access` warning on Java 9+. This PR uses Java 9 API to eliminate these warning. However, the consequence is, we need Java 9 compiler to compile the specific subproject `base-servces-java9`.

On Java 9+, `MethodHandles.Lookup` is used to invoke protected methods `ClassLoader.defineClass` and `ClassLoader.getDefinedPackage`.

  1. … 16 more files in changeset.
Improve laziness of gradlebuild by using build scans

  1. … 15 more files in changeset.
Add integration test for setting the channel for a distributed performance test