Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Simplify artifact types and make them more generic

  1. … 5 more files in changeset.
Differentiate between artifacts that are dirs/zips

- Add artifactType attributes to the api configuration and published


- Recognize directory artifacts and add explicit artifactType (instead

of "")

  1. … 8 more files in changeset.
Emit build operations around container callback executions (core and dependencyMgmt containers) (#7734)

* Decorate taskcontainer callbacks to track application id

* Decorate plugin container callbacks

* Decorate repositoryContainer callbacks

* Decoreate configurations and configuration.dependencies container callbacks

* Decorate artifactTypesDecorator callbacks

* Dont emit build ops for internal declared callbacks

* Provide usercode context in beforeResolve / afterResolve callbacks

* keep compatibility for nebula.dependency-recommender plugin

* Put domain collection callback build ops behind feature toggle

* Decorate Provider.configure() methods

* Simplify container callback filtering and decoration

Previously, we had three classes collaborating to achieve this but now this is inlined into effectively one. While this creates a more complex implementation, that is still rather simple, it avoids the more problematic complexity of a complicated relationship between the three implementations that also required extra state and details to be propagated through all of the collections.

  1. … 69 more files in changeset.
Consistently use component level attributes

Component-level attributes were only used if the component metadata was using Gradle

metadata. This was particularly confusing, as it was possible to define a component-

level attribute in a component-metadata rule, but it would be ignored during matching.

It was possible, however, to add attributes on variants of Ivy or Maven metadata,

but then the error messages in case there wasn't any match was even more confusing:

"Because there are no configurations with attributes"

This commit modifies the resolution engine so that it's possible to use component

level attributes independently of whether the underlying component metadata was

constructed from Ivy, Maven or Gradle metadata. It also changes the error messages

to mention either "configuration" or "variant" depending on whether the matching

strategy was using variant-aware dependency management *or* legacy configurations.

It was confusing because we have the `IMPROVED_POM_SUPPORT` flag which activates

variant construction from Maven metadata. This meant that in practice, if the flag

was active, we were using variants, but still the component level attributes were

not taken into account. If the flag wasn't active, then we would fail with the

error above, despite the fact we had rules on "configuration backed variants".

The separation of configuration/variant in error messages makes it easier for

us to understand in which case we are, since this wasn't always obvious. If we

see "variant", then now we know that the selection failed using the variant-aware

matching. If we see "configuration", then we know it's using the legacy mode.

This commit also needed to make the difference between "this component has no

variant" and "this component doesn't provide any mapping to variants", therefore

the introduction of the `Optional` on `getVariantsForTraversal`. This gives us

the opportunity to give the correct error message in case of failure using

the legacy mode.

Last but not least, this introduces a change in the attributes visible on variants

**and** artifacts. Before this commit, dependending on whether metadata was

Gradle metadata, the "status" attribute would be found or not. Now, the component

level attributes are _always_ merged to variant and artifact attributes, which

means that it's consistent independently of the format. This can be a breaking

change, but a low risk one.

  1. … 39 more files in changeset.
Do not pass variant attributes to `(single|multiple)Variants`

Instead, we make sure that the variant passed to the artifact set already contains the right set of

attributes. This involves wrapping the original `ComponentVariant` into a wrapper that will execute

the attribute rules lazily (and only once).

Signed-off-by: Cedric Champeau <>

  1. … 15 more files in changeset.
Pass variant attributes down to `DefaultArtifactSet` to avoid passing the rules there

This doesn't prevent the rules from being applied multiple times, but it will: now the

variant attributes are passed, meaning that once we cache the application of the rules,

they will only be computed once.

Signed-off-by: Cedric Champeau <>

  1. … 16 more files in changeset.
Rename the internal and test fixtures `VariantMetadata` to avoid confusion

Signed-off-by: Cedric Champeau <>

  1. … 24 more files in changeset.
Use the attributes factory to create mutable containers in addition to immutable containers, to decouple clients from the mutable container implementation and the things it may need.

  1. … 10 more files in changeset.
Only validate names for a selected set of domain objects

  1. … 6 more files in changeset.
Apply the attributes defined by artifact type metadata to a variant of something only when that something does not define any attributes already.

Added some Javadocs and unit test coverage.

    • -13
    • +29
  1. … 3 more files in changeset.
Apply the attributes defined for the matching artifact type to the files of a local file dependency.

  1. … 9 more files in changeset.
Added a public API reachable from `DependencyHandler` that allows a plugin to define attributes that should be attached to artifacts with a given extension, for example when consuming a Maven module or files defined by a file dependency.

The intention is that this meta-data about artifact types would complement (and maybe serve as input for) additional meta-data attached to a Maven/Ivy/local module by various meta-data rules.

    • -0
    • +26
    • -0
    • +51
    • -0
    • +86
  1. … 21 more files in changeset.