Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Try out compiling with tool as input to task

Relevant bits:

* JavaCompileWithJavaInstallationsIntegrationTest

* JavaCompile#getCompiler

  1. … 15 more files in changeset.
Use correct ReplacedBy annotations (#13165)

  1. … 1 more file in changeset.
Use correct ReplacedBy annotations

  1. … 1 more file in changeset.
Use correct ReplacedBy annotations

  1. … 1 more file in changeset.
Use correct ReplacedBy annotations

  1. … 1 more file in changeset.
Roll back setting main class in manifest

This change can be considered breaking and is postponed to Gradle 7.0.

Fixes #13057

  1. … 1 more file in changeset.
Roll back setting main class in manifest

This change can be considered breaking and is postponed to Gradle 7.0.

Fixes #13057

  1. … 1 more file in changeset.
Rename `o.g.a.i.lambdas.{Lambdas => SerializableLambdas}`

    • -1
    • +1
    ./internal/tasks/DefaultSourceSet.java
  1. … 5 more files in changeset.
Rename `o.g.a.i.lambdas.{Lambdas => SerializableLambdas}`

    • -1
    • +1
    ./internal/tasks/DefaultSourceSet.java
  1. … 5 more files in changeset.
Spike with installations container

  1. … 6 more files in changeset.
Fix warnings in java plugin

    • -123
    • +58
    ./plugins/JavaBasePlugin.java
Consider the derivation strategy when requesting component metadata

Gradle has a single, build scoped cache for dependency metadata. It's

using a build cache scope because component metadata is quite expensive

to read and process. However, component metadata _may_ be different

based on the plugins applied on a project. For example, Java projects

apply what we call a "Java derivation strategy", which is capable

of transforming regular POM files into so-called "platforms" but

more importantly, they are what map the different Maven scopes to

actual "variants" in variant-aware dependency management.

The problem is that it's not a requirement that all projects are

Java projects. It is possible to have native subprojects, or projects

which do _not_ apply the Java base plugin. While it's in general an

error to have a project which wants to perform "Java dependency

resolution" not to apply the Java derivation strategy, there are

consequences in not doing so. In particular, Gradle becomes order

dependent: if a subproject which does not apply the derivation

strategy resolves a module first, then subsequent resolutions for

projects which _do_ apply the derivation strategy would get wrong

metadata.

To avoid this, this commit makes sure that when we consume module

metadata, we actually use the derivation strategy as part of the

processed metadata cache key.

This does _not_ fix the fact that the consumers _should have_ applied

the derivation strategy and will make realizing this harder, but it

_does_ fix the inconsistency in resolution, which is probably a

much bigger issue (for caching and reproducibility).

  1. … 11 more files in changeset.
Consider the derivation strategy when requesting component metadata

Gradle has a single, build scoped cache for dependency metadata. It's

using a build cache scope because component metadata is quite expensive

to read and process. However, component metadata _may_ be different

based on the plugins applied on a project. For example, Java projects

apply what we call a "Java derivation strategy", which is capable

of transforming regular POM files into so-called "platforms" but

more importantly, they are what map the different Maven scopes to

actual "variants" in variant-aware dependency management.

The problem is that it's not a requirement that all projects are

Java projects. It is possible to have native subprojects, or projects

which do _not_ apply the Java base plugin. While it's in general an

error to have a project which wants to perform "Java dependency

resolution" not to apply the Java derivation strategy, there are

consequences in not doing so. In particular, Gradle becomes order

dependent: if a subproject which does not apply the derivation

strategy resolves a module first, then subsequent resolutions for

projects which _do_ apply the derivation strategy would get wrong

metadata.

To avoid this, this commit makes sure that when we consume module

metadata, we actually use the derivation strategy as part of the

processed metadata cache key.

This does _not_ fix the fact that the consumers _should have_ applied

the derivation strategy and will make realizing this harder, but it

_does_ fix the inconsistency in resolution, which is probably a

much bigger issue (for caching and reproducibility).

  1. … 11 more files in changeset.
Spike using named domain collection and installation as task input

    • -0
    • +23
    ./plugins/JavaInstallationsContainer.java
    • -0
    • +43
    ./plugins/internal/DefaultJavaInstallationsContainer.java
  1. … 4 more files in changeset.
Apply the Java derivation strategy to the Java Platform plugin

This commit makes sure that the Java Platform plugin also applies the

Java derivation strategy, as it, as it names indicates, also belongs

to the Java ecosystem. Not doing so triggers some weird ordering issues

if another project, which is a Java library, tries to resolve the same

dependencies as the Java platform, but after the platform has resolved

them.

Because of component metadata caching, the first project to resolve

a dependency will be the "source of truth" for dependency metadata for

the module for the whole build. It means that if it was a Java library,

then the derivation strategy was applied and the project could resolve

everything properly. However, if the first project to trigger resolution

of a module was a Java Platform, then we would cache component metadata

_without_ derivation. This means, in particular, that platforms wouldn't

be derived for external Maven modules.

This explains why in #12728, order of execution of tasks matters: if

the subproject was resolved _first_ (gradle sub:compileJava resolve)

then everything was fine, but if the platform was resolved first, then

the rest of the build would fail.

The fix is to apply the derivation strategy to the Java platform plugin

too. However, in an ideal world, we should refactor the Java plugins so

that they consist of several layers:

- a "schema" layer, configuring the ecosystem schema, the derivation strategy, ...

- a "base" layer, consisting of what the Java Base plugin does today

- a "platform", directly on top of "schema"

- an application, and a "library", on top of "base"

Fixes #12728

  1. … 1 more file in changeset.
Apply the Java derivation strategy to the Java Platform plugin

This commit makes sure that the Java Platform plugin also applies the

Java derivation strategy, as it, as it names indicates, also belongs

to the Java ecosystem. Not doing so triggers some weird ordering issues

if another project, which is a Java library, tries to resolve the same

dependencies as the Java platform, but after the platform has resolved

them.

Because of component metadata caching, the first project to resolve

a dependency will be the "source of truth" for dependency metadata for

the module for the whole build. It means that if it was a Java library,

then the derivation strategy was applied and the project could resolve

everything properly. However, if the first project to trigger resolution

of a module was a Java Platform, then we would cache component metadata

_without_ derivation. This means, in particular, that platforms wouldn't

be derived for external Maven modules.

This explains why in #12728, order of execution of tasks matters: if

the subproject was resolved _first_ (gradle sub:compileJava resolve)

then everything was fine, but if the platform was resolved first, then

the rest of the build would fail.

The fix is to apply the derivation strategy to the Java platform plugin

too. However, in an ideal world, we should refactor the Java plugins so

that they consist of several layers:

- a "schema" layer, configuring the ecosystem schema, the derivation strategy, ...

- a "base" layer, consisting of what the Java Base plugin does today

- a "platform", directly on top of "schema"

- an application, and a "library", on top of "base"

Fixes #12728

  1. … 1 more file in changeset.
Spike how toolchain support could look like

Relevant bits are in JavaToolchainCompileIntegrationTest

Basic idea is that the toolchain is configured on the JavaPluginExtension

Core tasks that require the toolchain (javac, javadoc, ) expose a toolchain property and add a convention to the extension.

Externals tasks (e.g. jlink) can do the same.

Build authors are able to add more tasks and set the toolchain accordingly (API is still missing to get/add the toolchains)

    • -6
    • +19
    ./plugins/internal/DefaultJavaPluginExtension.java
  1. … 6 more files in changeset.
Use plugins DSL in Javadoc code snippets

    • -1
    • +3
    ./plugins/ApplicationPluginConvention.java
  1. … 41 more files in changeset.
Use plugins DSL in Javadoc code snippets

    • -1
    • +3
    ./plugins/ApplicationPluginConvention.java
  1. … 41 more files in changeset.
Restore the ability to define JavaExec.main via task convention (#12836)

  1. … 3 more files in changeset.
Restore the ability to define JavaExec.main via task convention

  1. … 3 more files in changeset.
Restore the ability to define JavaExec.main via task convention

  1. … 3 more files in changeset.
Polish `JavaPlugin`

- Replace anonymous inner class by lambda

- Shorten lines by deduping long expressions

When a strict `Property` is read, finalize all properties whose values are used to calculate the property's final value.

    • -1
    • +1
    ./internal/plugins/DefaultArtifactPublicationSet.java
  1. … 42 more files in changeset.
When a strict `Property` is read, finalize all properties whose values are used to calculate the property's final value.

    • -1
    • +1
    ./internal/plugins/DefaultArtifactPublicationSet.java
  1. … 42 more files in changeset.
When a strict `Property` is read, finalize all properties whose values are used to calculate the property's final value.

    • -1
    • +1
    ./internal/plugins/DefaultArtifactPublicationSet.java
  1. … 36 more files in changeset.
When a strict `Property` is read, finalize all properties whose values are used to calculate the property's final value.

    • -1
    • +1
    ./internal/plugins/DefaultArtifactPublicationSet.java
  1. … 42 more files in changeset.
When a strict `Property` is read, finalize all properties whose values are used to calculate the property's final value.

    • -1
    • +1
    ./internal/plugins/DefaultArtifactPublicationSet.java
  1. … 36 more files in changeset.
Remove 'release' property (reverts #12648)

A more high level concept for specifying Java versions will

be introduced soon.

    • -10
    • +3
    ./plugins/internal/DefaultJavaPluginConvention.java
    • -2
    • +11
    ./plugins/internal/JvmPluginsHelper.java
  1. … 9 more files in changeset.
Remove 'release' property (reverts #12648)

A more high level concept for specifying Java versions will

be introduced soon.

    • -10
    • +3
    ./plugins/internal/DefaultJavaPluginConvention.java
    • -2
    • +11
    ./plugins/internal/JvmPluginsHelper.java
  1. … 9 more files in changeset.