build.gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Convert buildSrc/settings.gradle & buildSrc/build.gradle to Kotlin (#3888)

To convert a first plugin from Groovy to Kotlin, the `kotlin-dsl`

plugin needs to be applied to buildSrc. This plugin is provided by the

Gradle Kotlin DSL, it configures the Project for building plugins

written using the Kotlin DSL.

But, first things first, this commit converts the buildSrc build scripts

to Kotlin.

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

  1. … 3 more files in changeset.
Convert `buildSrc/build.gradle` to Kotlin

  1. … 1 more file in changeset.
Let buildSrc use the java-gradle-plugin plugin (#3574)

* buildSrc use the java-gradle-plugin plugin

* Rename plugin id from org.gradle.build-types to build-types

  1. … 4 more files in changeset.
Formatting

Favour declarative plugin application in buildSrc

Upgrade asciidoctor plugin version to 1.5.6 for Java versions 8+

Polish internal plugin identifiers

- Get rid of the `Gsk` prefix

- Map PascalCase type names to camelCase collection ids to kebab-case

plugin ids

  1. … 7 more files in changeset.
Only update asciidoctorj to 1.5.6 and leave plugin at 1.5.3

With the upgrade from 1.5.3 -> 1.5.6, the asciidoctor-gradle-plugin

makes use of Java8 API (Map.computeIfAbsent) and thus we can not use it.

But we need asciidoctorj upgrade for the file handle leak fix.

  1. … 1 more file in changeset.
Upgrade asciidoctor plugin to 1.5.6 + remove file handle leak workaround

This also upgrades asciidoctorj to 1.5.6 which fixes the file handle

leak issue. For details, see:

https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/214#issuecomment-338167813

  1. … 1 more file in changeset.
Expose `kotlin-stdlib-jre8` to build scripts

See #558

  1. … 9 more files in changeset.
Improve binary compatibility check report

The report now corresponds to what we had in the JDiff reports before:

- It also shows changes to Incubating API

- It excludes some more redundant change types for better readability

The report generator now also reports (and fails) for missing @since

tags. This is implemented by checking the source of a class that

includes new API elements suing the 'com.github.javaparser'.

Only changes to non-incubating public API need to be accepted

explicitly in accept-public-api-changes.json.

  1. … 8 more files in changeset.
Generate plugin markers for buildSrc plugins

Apply java-gradle-plugin plugin to buildSrc

:arrow-up: Kotlin 1.1.50 :tada:

And migrate to the new compiler flags for JSR-305 support

  1. … 2 more files in changeset.
Make doc tasks cacheable

  1. … 5 more files in changeset.
Make doc tasks cacheable

  1. … 5 more files in changeset.
Enable jsr305 annotations on `buildSrc`

  1. … 2 more files in changeset.
Remove taskCacheDetailedDiagnosticsInit.gradle

All the information is now present in build scans.

We shouldn't use our own statistics script any more.

+review REVIEW-6564

  1. … 4 more files in changeset.
Filter and package reports/logs for CI publishing

This reduces the reports that are published to the ones that we

always want to see (i.e. binary compatibility) and the ones of

failing tasks. Reports that consist of multiple files are zipped.

This serves two purposes:

- TC Performance: less publishing time and disc space use

- Analysing failed builds: less clutter by only providing reports of

what actually failed

  1. … 2 more files in changeset.
Update to japicmp-plugin 0.2.4

+review REVIEW-6552

  1. … 1 more file in changeset.
Make use of the `japicmp` plugin to check for binary compatibility

This commit introduces the use of the JApiCmp plugin to check for binary compatibility between releases of Gradle.

The binary compatibility checks now generate a report per project, based on the last release version. Accepted

changes need to be added to the `distributions/src/changes/changes-since-x.y.txt` file.

- The build will fail if a non accepted, binary breaking change, is introduced.

- Removes the binary breaking change test as it is superceded by the plugin use

- Uses a single binary compatibility check task for all projects, which aggregates classpath

This commit addresses a concern with regards to refactoring between modules. With individual reports, some errors would occur because

we moved classes from one module to the other, while, in practice, all are shipped together (as of now). This means that you cannot,

in practice, consider all artifacts as separate. They form a whole which is "the Gradle API", for good or for bad.

The custom rules:

- automatically accept changes based on our `@Incubating` policy

- make sure that all rules declared in `changes-since.txt` are matched

This plugins adds a sanity check, making sure that all the regressions that we declare

as accepted in the `changes-since` file actually match a rule. If not, the build will

fail, requiring to review this file.

Binary compatibility checks is executed as part of `sanityCheck` and `check`.

  1. … 14 more files in changeset.
Bump cglib in `buildSrc` too

  1. … 2 more files in changeset.
Remove build operation listener at end of build

This prevents problems when applying the same custom values script to

buildSrc.

  1. … 1 more file in changeset.
Gather custom scan data for buildSrc

when running buildSrc as standalone project.

Use BuildOperationListener for buildScan custom values

`BuildOperationNotificationListener` will not work since only one

notification listener is allowed there. And this one is already used by

the build scan plugin.

Note that I removed the application of the build scan custom values

script from `buildSrc` since the listener is build tree scoped and so

the `buildSrc` listener would be present in the main build as well

whereas the build scan plugin already determined that the build is

finished causing `The buildScan extension cannot be used after the build has finished.`

warnings in the main build.

  1. … 1 more file in changeset.
Extract common project configuration logic to `GskModule` plugin

  1. … 8 more files in changeset.
Revert "Remove snapshot repos"

This reverts commit 2261a843578f083cb7ef6ca4eda3342831e15fe8.

+review REVIEW-6505

  1. … 1 more file in changeset.
Remove snapshot repos

+review REVIEW-6505

  1. … 1 more file in changeset.
Remove unnecessary comments

Looks like these additional repositories are not causing any major trouble, so let’s leave them in.

+review REVIEW-6510

  1. … 1 more file in changeset.
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

  1. … 2 more files in changeset.