Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Require documentation or explicit undocumented() when nagging of deprecations

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
  1. … 63 more files in changeset.
Encapsulate ConfigurationDeprecationType enum behind a builder

    • -2
    • +1
    ./LocalComponentDependencyMetadata.java
  1. … 8 more files in changeset.
Add fluent configuration deprecation message builder

    • -2
    • +2
    ./LocalComponentDependencyMetadata.java
  1. … 8 more files in changeset.
Lambda-ification of the dependency management project

This makes the code base easier to read.

  1. … 65 more files in changeset.
Replace nagUserWith(builder) usages with builder.nagUser()

    • -5
    • +4
    ./LocalComponentDependencyMetadata.java
  1. … 61 more files in changeset.
Move DeprecationLogger to internal.deprecation package

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
  1. … 79 more files in changeset.
Extract replaced configuration and replaced property message builders

    • -2
    • +3
    ./LocalComponentDependencyMetadata.java
  1. … 34 more files in changeset.
Replace configurationHasBeenReplaced() with DeprecationMessage builder

    • -1
    • +2
    ./LocalComponentDependencyMetadata.java
  1. … 9 more files in changeset.
Add more test coverage for deleted artifacts

  1. … 5 more files in changeset.
Track composition of Maven module metadata

The binary representation of a Maven POM was only tracking the

POM file itself as the source. However, a POM can reference

parent POMs which also participate in resolution. This commit

changes the `ModuleSources` so that we can query more than one

module source of a specific type, allowing us to store more

than a single module source for a single file.

  1. … 4 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -0
    • +54
    ./PersistentModuleSource.java
  1. … 38 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

    • -0
    • +119
    ./ImmutableModuleSources.java
    • -0
    • +32
    ./ModuleSources.java
    • -0
    • +108
    ./MutableModuleSources.java
    • -0
    • +21
    ./WrappedComponentResolveMetadata.java
  1. … 60 more files in changeset.
Allow only virtual components as platform owners

The concept of n 'platform owner' for a node was introduced to deal with

virtual platforms, where no real node exists for a platform.

Since this is now the only case where this functionality is used,

we limit it to that.

  1. … 8 more files in changeset.
Compute checksums concurrently

This commit reworks how checksums are computed by computing

them concurrently between projects. Checksums are computed

in parallel, however we preserve write order. This involves

a bit more memory usage but it proves to be faster.

  1. … 3 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

  1. … 32 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 6 more files in changeset.
Track 'changing' and 'client module' information for override metadata

Although these are edge cases, it leads to more consistency and makes

the behavior less dependent on order which may change unexpectedly

through internal optimisations.

    • -3
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 6 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

    • -6
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

    • -6
    • +6
    ./DefaultComponentOverrideMetadata.java
  1. … 9 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Reuse one object for empty ComponentOverrideMetadata

    • -2
    • +4
    ./DefaultComponentOverrideMetadata.java
  1. … 3 more files in changeset.
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Avoid copying an already immutable list

    • -1
    • +1
    ./LocalComponentDependencyMetadata.java
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

  1. … 66 more files in changeset.
Revert "Merge branch 'release'"

This reverts commit c7fdc455dcb9a8016af0ae9bc8b4c43fde1e2d06, reversing

changes made to 9f70d52b74dbc8c71381781b6c155474031b3cf8.

The changes need a wrapper as there are API changes. Reverting for now.

  1. … 66 more files in changeset.
Fix AttributeConfigurationSelector to return the filtered result 2/2

Same as 3255f1d for different code path.

  1. … 1 more file in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions() (#10755)

This name change more clearly communicates the semantics of the

feature from a users point of view.

This commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

would have been misleading in the future. To make sure we catch all,

this also updates all variable/method/package names.

    • -10
    • +10
    ./LocalComponentDependencyMetadata.java
  1. … 69 more files in changeset.
Support variant and file derivation in realized metadata

This required a couple of changes:

- artifacts are now always explicitly serialized for each configuration

- variant derivation is implemented for variants and for configurations

in maven (derived variants) and ivy

- If a ivy module has configurations (variants) that have been added by

a rule, the realized version uses this information to opt-into

variant aware resolution

  1. … 15 more files in changeset.
Make evaluation of base variant rules lazy

  1. … 6 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +1
    ./DefaultSelectedByVariantMatchingConfigurationMetadata.java
    • -1
    • +2
    ./DefaultSelectedByVariantMatchingLocalConfigurationMetadata.java
  1. … 11 more files in changeset.