Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
De-incubate latest dependency management APIs for 6.0 (#10886)

These are APIs that complete features which are fully implemented and

de-incubated in Gradle 6.

  1. … 7 more files in changeset.
De-incubate a number of dependency management related APIs

  1. … 107 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

  1. … 3 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryelements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -0
    • +65
  1. … 45 more files in changeset.
Mark VersionContraint and Category as used by scan plugin

Signed-off-by: Volker Leck <>

  1. … 1 more file in changeset.
Mark AttributeContainer as used by scan plugin

Signed-off-by: Volker Leck <>

Remove utilisation of *-jars usage values

  1. … 55 more files in changeset.
Add new standard attributes

* org.gradle.format: indicates the format of the artifacts of the

variant. Note that this is different than the artifactType attribute.

* org.gradle.docstype: Used for docs category to clarify more what type

of documentation this variant represents.

Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle


  1. … 27 more files in changeset.
To avoid confusion, remove mention of "platform" from "target Java platform"

We already have the "Java Platform" plugin which is something quite

different from the concept we want to express when using "target java platform".

This is more often known as the "JVM version", or "target Java version". We

use "JVM" because this is not specific to Java.

    • -0
    • +34
  1. … 24 more files in changeset.
Allow `RegularFileProperty` and `DirectoryProperty` types to be used on artifact transform parameter objects, and take care of fingerprinting and building the files before running the transform.

Reuse the mechanism that allows instances of generated classes to describe their state to the isolation infrastructure for other core Gradle types, such as `ConfigurableFileCollection`, `Provider` and `Property` and remove the custom isolation logic for these core types.

  1. … 38 more files in changeset.
Rename the Java target platform attribute

This is to avoid confusion: while "minimal" makes sense from

the producer point of view, it reads strange when seen from

the consumer side: the "minimal" version here can be higher

than what a producer has. So it's now simplified to "target


  1. … 15 more files in changeset.
Generalize bundling attribute

The scope of this attribute goes beyond the Java ecosystem. So it is

defined at the same level as the usage attribute.

Issue #8380

  1. … 5 more files in changeset.
Introduce `TargetJavaPlatform` attribute

This commit adds a new Java ecosystem attribute, corresponding

to the minimal target platform a producer supports. It's often

the case that Java libraries are published with different

classifiers for different target platforms. However, a classifier

is not enough. With this attribute, we now have a proper model

of the producer and consumer side.

By default, the producer will not ask for a specific target

platform, but will only accept those which are lower than or

equal to the current Gradle runtime version. However, if the

consumer says something, it will then select the most appropriate

variant based on the producer attributes.

In the Java world, a consumer can use Java libraries produced

for older versions of Java, but not newer versions. This rule

is baked in as the default compatibility rule. Disambiguation

will then chose the closest version.

    • -0
    • +34
  1. … 23 more files in changeset.
Clarify attribute compatibility rule contract

The provided details will never have equal consumer and producer values

as that check is performed before invoking the rule.

This also means that equal values are determined to be always


Fixes #8518

  1. … 2 more files in changeset.
Rename `DependencyPacking` -> `Bundling`

This avoids the name collision with OSGi "bundle", while

also being closer to what we want to express. It also

changes the "fatjar" value to "embedded" so that this

attribute can be used in a wider context (like, "all"


    • -0
    • +56
  1. … 13 more files in changeset.
Introduce a `packing` attribute for the Java ecosystem

This attribute is there to represent how dependencies are

packaged for a variant. There are 3 possible options:

- external, which is the most common case, where dependencies

are found in individual jars

- fatfar, where some or all dependencies are directly repackaged

into the main jar

- shadowed, where some or all dependencies are directly repackaged

into the main jar, but also "shadowed" by moving them in a different

package in order to avoid name clashes

    • -0
    • +53
    • -0
    • +21
  1. … 2 more files in changeset.
Introduce a `JAVA_API_JARS` usage

This commit introduces a new `JAVA_API_JARS` usage, mirror

to the `JAVA_RUNTIME_JARS` usage. This is both for consistency,

and to make sure that the `JAVA_API` and `JAVA_RUNTIME` usages

are limited to cases where the consumer doesn't care, or when

a producer doesn't have a more specific usage to provide.

This is, for example, the case for Java platforms. It's worth

noting than in case a producer mixes both "generic" usages

and "specific" usages, selection is likely to produce unexpected

results, because of disambiguation rules.

The Java disambiguation rule has been simplified and now

supports more cases.

  1. … 37 more files in changeset.
spelling: supposedly

Signed-off-by: Josh Soref <>

  1. … 1 more file in changeset.
De-incubate old API

All the de-incubated methods are either internal API or don't have a

since Javadoc.

  1. … 22 more files in changeset.
De-incubate 3.x dependency management API

  1. … 20 more files in changeset.
Renamed the usage attribute (not the class).

  1. … 1 more file in changeset.
Removed validation from `Attribute.of()`, as the set of valid types is a function of how and where the attribute is used. Instead, moved the validation to `AttributeContainer.attribute()` to accept anything that can be made isolated.

Added some functional test coverage for how attribute values behave.

  1. … 5 more files in changeset.
Cover `org.gradle.api.attributes` with nullability annotations

Extract :core-api project (#2719)

    • -0
    • +30
    • -0
    • +83
    • -0
    • +30
    • -0
    • +61
    • -0
    • +74
    • -0
    • +51
    • -0
    • +81
    • -0
    • +85
    • -0
    • +35
    • -0
    • +39
    • -0
    • +56
  1. … 772 more files in changeset.
Make the verification of `Named` immutables stricter

This commit addresses review feedback: the check on `Named` was only checking that the user provided a type

extending `Named`, but they could very well provide a concrete type, which wouldn't be immutable. By making

sure we can only use an interface, then users can only use `Named` types which are actually not instantiable

directly. This won't prevent from passing a value which is a concrete type, but it will prevent declaring

attributes of mutable types.

  1. … 3 more files in changeset.
Limit the type of attributes to types we can make immutable

This commit restricts the possibilities of custom types for attributes. Since attributes are used in various

places, potentially different classloaders or even different process, we need a stable way to make them

both snapshottable and serializable. This commit is the first step, by making it impossible to create attributes

with arbitrary types.

Types that we support include:

- scalar types, which are primitive types (and their wrappers), `File` or `String` (aka, known immutables)

- a type extending `Named`, in which case it is expected to create values using the `ObjectFactory`

- an enum

- an array of the above (arrays are not immutable, but we can create immutable values out of arrays)

Some tests had to be adjusted, because they didn't match those constraints. Future work will include possibilities

to include richer types.

  1. … 5 more files in changeset.
Remove `FOR_COMPILE` and `FOR_RUNTIME` from Usage

The constants had been replaced internally, except for publication. This commit removes them in favor of

using the more specific `JAVA_API` and `JAVA_RUNTIME` constants (in their string forms, making it possible

later to match by value, avoiding classloading issues).

  1. … 8 more files in changeset.