Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add lenient version of ComponentMetadataDetails.addVariant() (#11565)

    • -6
    • +8
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -0
    • +47
    ./model/AdditionalVariant.java
    • -12
    • +14
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
    • -10
    • +13
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -10
    • +13
    ./model/maven/RealisedMavenModuleResolveMetadata.java
  1. … 5 more files in changeset.
De-duplicate entries based on file name instead of artifact id

Because Gradle internally sometimes uses `DefaultModuleComponentArtifactIdentifier`

or `ModuleComponentFileArtifactIdentifier` for the same artifact depending on the

context, we can't rely on equality here. This commit changes the internal verification

structure to rely on the file name which is more consistent and fixes duplication

issues.

    • -1
    • +3
    ./model/DefaultModuleComponentArtifactIdentifier.java
  1. … 8 more files in changeset.
Always serialize module sources

Module sources were only serialized in the cache metadata entry.

In practice, they belong to the module metadata, so they are now

properly serialized as part of it. This fixes the "force realize"

tests.

    • -7
    • +0
    ./model/ModuleComponentResolveMetadata.java
  1. … 18 more files in changeset.
Use file names instea of Ivy artifact names for comparison

This commit reworks the generation of verification file and

verification itself in order to use the file name instead of

the Ivy artifact name. This is done because in case of Gradle

module metadata, the file name of an artifact is not necessarily

directly bound to the module name and causes comparison issues.

    • -2
    • +0
    ./model/ModuleComponentArtifactIdentifier.java
    • -7
    • +0
    ./model/ModuleComponentFileArtifactIdentifier.java
  1. … 9 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.

    • -15
    • +2
    ./model/AbstractModuleComponentResolveMetadata.java
    • -15
    • +0
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -6
    • +0
    ./model/ModuleComponentResolveMetadata.java
    • -7
    • +0
    ./model/MutableModuleComponentResolveMetadata.java
  1. … 36 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.

    • -4
    • +3
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -12
    • +12
    ./model/AbstractModuleComponentResolveMetadata.java
    • -8
    • +10
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -3
    • +3
    ./model/AbstractRealisedModuleComponentResolveMetadata.java
    • -1
    • +1
    ./model/MetadataSourcedComponentArtifacts.java
    • -6
    • +14
    ./model/ModuleComponentResolveMetadata.java
    • -3
    • +5
    ./model/MutableModuleComponentResolveMetadata.java
    • -8
    • +8
    ./model/ivy/DefaultIvyModuleResolveMetadata.java
    • -7
    • +0
    ./model/ivy/IvyModuleResolveMetadata.java
    • -6
    • +6
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -7
    • +7
    ./model/maven/DefaultMavenModuleResolveMetadata.java
    • -7
    • +0
    ./model/maven/MavenModuleResolveMetadata.java
    • -5
    • +5
    ./model/maven/RealisedMavenModuleResolveMetadata.java
  1. … 51 more files in changeset.
Remove offending 'break' from loop

    • -1
    • +0
    ./model/maven/RealisedMavenModuleResolveMetadataSerializationHelper.java
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.

    • -4
    • +3
    ./model/AbstractModuleComponentResolveMetadata.java
    • -4
    • +3
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -5
    • +4
    ./model/MutableModuleComponentResolveMetadata.java
  1. … 6 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

    • -0
    • +3
    ./model/ModuleComponentArtifactIdentifier.java
    • -0
    • +7
    ./model/ModuleComponentFileArtifactIdentifier.java
  1. … 31 more files in changeset.
Handle serialization for shadowed capabilities in the GMM case (#11179)

This is now done in the same way as it is done in the

AbstractRealisedModuleResolveMetadataSerializationHelper

for cases without GMM

Follow up to: #11118

    • -0
    • +5
    ./model/AbstractMutableModuleComponentResolveMetadata.java
  1. … 3 more files in changeset.
Fix imports for Nullable annotation

    • -1
    • +1
    ./model/LazyRuleAwareWithBaseConfigurationMetadata.java
  1. … 1 more file in changeset.
Rename: `-enforced-platform` -> `-derived-enforced-platform`

    • -1
    • +1
    ./model/JavaEcosystemVariantDerivationStrategy.java
  1. … 4 more files in changeset.
Use a different 'shadow capability' for enforced platform

This allows both 'regular' and 'enforced' platform of the same

component to be selected. In order to make this work, support

for projects having shadow capability needed to be added.

    • -8
    • +38
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -2
    • +2
    ./model/DefaultShadowedCapability.java
    • -5
    • +6
    ./model/JavaEcosystemVariantDerivationStrategy.java
    • -0
    • +10
    ./model/MutableComponentVariant.java
    • -3
    • +2
    ./model/MutableModuleComponentResolveMetadata.java
    • -3
    • +15
    ./model/ProjectDerivedCapability.java
  1. … 7 more files in changeset.
Compatibility fix for Gradle Module Metadata

This fix will enable Gradle 5.6.3 to consume Gradle Module Metadata for

-SNAPSHOT produced by Gradle 6+

Fixes #11050

    • -4
    • +39
    ./model/UrlBackedArtifactMetadata.java
Add compatibility layer for SNAPSHOT metadata

Gradle 5.3 to 5.6 have an issue when publishing a Gradle Module Metadata

with a unique snapshot.

This commit enables Gradle 6+ to consume such metadata files without

error.

Fixes #9462

    • -0
    • +10
    ./model/AbstractMutableModuleComponentResolveMetadata.java
  1. … 3 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -0
    • +46
    ./model/DefaultComponentVariantIdentifier.java
    • -1
    • +13
    ./model/maven/DefaultMutableMavenModuleResolveMetadata.java
  1. … 65 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.

    • -46
    • +0
    ./model/DefaultComponentVariantIdentifier.java
    • -13
    • +1
    ./model/maven/DefaultMutableMavenModuleResolveMetadata.java
  1. … 65 more files in changeset.
Support variant selection in capability conflict resolution (#10973)

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

    • -0
    • +46
    ./model/DefaultComponentVariantIdentifier.java
  1. … 13 more files in changeset.
Changes in Gradle Module Metadata loading

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

Fixes #10980

    • -1
    • +13
    ./model/maven/DefaultMutableMavenModuleResolveMetadata.java
  1. … 16 more files in changeset.
Fix realization of Maven metadata

The fix to handle SNAPSHOT dependencies correctly with Gradle

Module Metadata exposed a couple of failures in the "force

realize" cases, which correspond to the cases where metadata

has to be realized pre-emptively (using cached metadata rules

for example).

    • -1
    • +18
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
  1. … 1 more file in changeset.
Fix snapshot handling with Gradle Module Metadata

This commit fixes a couple of bugs:

1. if Gradle Module Metadata was published and consumed, then

the `changing` flag for the resolved component metadata wouldn't

be set to `true`, which means that snapshot would effectively be

considered as persistent

2. the publish test fixtures were not using the right, timestamped,

version id for the metadata and artifacts in case of unique snapshots,

which caused the resolution to fallback to the POM file

In addition, this fixes the generated module metadata file which

was uploaded _without_ substution the the SNAPSHOT version with

the timestamped version when published on external repositories.

Finally, this highlighted a couple of issues with test fixtures

which were still using Gradle Module Metadata when they shouldn't.

Fixes #10916

    • -4
    • +29
    ./model/UrlBackedArtifactMetadata.java
  1. … 10 more files in changeset.
Re-use immutable capabilities objects in configuration metadata objects

    • -6
    • +4
    ./model/DefaultConfigurationMetadata.java
    • -6
    • +5
    ./model/JavaEcosystemVariantDerivationStrategy.java
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.

    • -7
    • +7
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -3
    • +3
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -1
    • +1
    ./model/AbstractVariantBackedConfigurationMetadata.java
    • -8
    • +8
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -4
    • +4
    ./model/ForcedDependencyMetadataWrapper.java
    • -14
    • +14
    ./model/GradleDependencyMetadata.java
    • -1
    • +1
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
    • -4
    • +4
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 60 more files in changeset.
Fix application of dependency rules in realized metadata version

The rules for dependencies and dependency constraints were not applied

if the variant itself was added by a rule.

This commit also no longer attempts to apply any rule to the realized

version of 'pure maven configurations'. For Maven, we always use the

derived variants and always use variant matching. Therefore, rules are

never applied to the legacy configurations, but only to the derived

variants.

Follow up to #10368

    • -2
    • +1
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -14
    • +16
    ./model/maven/RealisedMavenModuleResolveMetadata.java
  1. … 1 more file in changeset.
Updates to terminology for clarity

- `inheritStrictConstraints` -> `inheritStrictVersions`

- `notInheritStrictConstraints` -> `doNotInheritStrictVersions`

    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 27 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -1
    • +1
    ./ivypublish/DefaultIvyModulePublishMetadata.java
    • -1
    • +1
    ./model/ConfigurationBoundExternalDependencyMetadata.java
    • -2
    • +2
    ./model/ForcedDependencyMetadataWrapper.java
    • -2
    • +2
    ./model/ModuleDependencyMetadataWrapper.java
  1. … 72 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

    • -3
    • +8
    ./model/AbstractConfigurationMetadata.java
    • -2
    • +2
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -0
    • +45
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -8
    • +5
    ./model/DefaultConfigurationMetadata.java
    • -8
    • +60
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
    • -1
    • +1
    ./model/LazyVariantBackedConfigurationMetadata.java
    • -5
    • +18
    ./model/RealisedConfigurationMetadata.java
    • -0
    • +6
    ./model/UrlBackedArtifactMetadata.java
    • -18
    • +98
    ./model/ivy/RealisedIvyModuleResolveMetadata.java
    • -11
    • +26
    ./model/ivy/RealisedIvyModuleResolveMetadataSerializationHelper.java
    • -22
    • +72
    ./model/maven/RealisedMavenModuleResolveMetadata.java
    • -3
    • +10
    ./model/maven/RealisedMavenModuleResolveMetadataSerializationHelper.java
  1. … 3 more files in changeset.
Serialize dependency artifacts in for realized variant of metadata

Addition to #10372

    • -2
    • +3
    ./model/AbstractRealisedModuleResolveMetadataSerializationHelper.java
    • -4
    • +4
    ./model/AbstractVariantBackedConfigurationMetadata.java
    • -1
    • +11
    ./model/GradleDependencyMetadata.java
    • -4
    • +4
    ./model/LazyToRealisedModuleComponentResolveMetadataHelper.java
  1. … 3 more files in changeset.
Make evaluation of base variant rules lazy

    • -1
    • +1
    ./model/AbstractConfigurationMetadata.java
    • -23
    • +3
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -1
    • +1
    ./model/AbstractMutableModuleComponentResolveMetadata.java
    • -0
    • +153
    ./model/LazyRuleAwareWithBaseConfigurationMetadata.java
    • -11
    • +3
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 2 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
    • +5
    ./model/AbstractLazyModuleComponentResolveMetadata.java
    • -5
    • +8
    ./model/LazyVariantBackedConfigurationMetadata.java
  1. … 13 more files in changeset.