Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Make 'guava' a common dependency for all projects

    • -0
    • +1
  1. … 71 more files in changeset.
Make 'slf4j_api' a common dependency for all projects

    • -0
    • +7
  1. … 64 more files in changeset.
Make use of the Java Platform plugin for distribution dependencies

    • -3
    • +3
  1. … 1 more file in changeset.
Dogfood Kotlin DSL improvements in build scripts

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

    • -2
    • +2
  1. … 13 more files in changeset.
Fix typo in distributions-dependencies.gradle.kt

    • -1
    • +1
Use capabilities to declare incompatiblities between modules

This commit changes the dependency metadata rules to use capababilities when it makes

sense. Capabilities can be used to declare that two modules are providing the same

functionality, so it's illegal to have them both on classpath. In this case, we choose

one module over the other. However, in some cases, we want to always use the newer

capability provider, even when there's no conflict, so there are two possibilities:

- `select()` will "soft choose", just in case of conflict

- `forceUpgrade()` will always replace a dependency with the preferred provider

In general, `select()` should be enough, but there are limitations. For example, we

can explain that `org.ow2.asm:asm:6.1` provides `asm:asm:6.1`, and that `org.ow2.asm:asm-tree:6.1`

provides `asm:asm-tree:6.1`. In this case, if the dependency graph contains:

- `asm:asm-tree:3.1` -> `asm:asm:3.1`

- `org.ow2.asm:asm:6.1`

Then we will automatically upgrade `asm:asm:3.1` to `6.1`, but _not_ `asm-tree`, because

there's no conflict for this module. As we cannot guarantee it's a compatible combination,

we forcefully upgrade all modules of "ASM" to the same version.

Technically, this feature relies on the "capabilities" feature of Gradle 4.7. Since no external

module declares any capability, we need to do 2 things:

1. use rules to declare the capabilities for external modules

2. fix the conflicts when they happen

We chose to automatically generate a synthetic capability for all modules that provide the same

capability, and rely on automatic upgrade to fix the conflicts. For example, if modules `A`, `B`

and preferred module `C` provide the same capability `cap`, then:

- `A` is assigned capability `cap` version `1`

- `B` is assigned capability `cap` version `2`

- `C` is assigned capability `cap` version `3`

This way, when `A` and `B` are in conflict, we will prefer `B`. When `B` and `C` are in conflict,

we will prefer `C`.

    • -16
    • +0
  1. … 2 more files in changeset.
Convert dependency management script to kotlin-dsl (#4465)

Wrapper update is required because of: ba08e0e

    • -0
    • +65
  1. … 7 more files in changeset.