ResolveIvyFactoryTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

  1. … 102 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

  1. … 102 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

  1. … 102 more files in changeset.
Introduce a checksum file cache service

This service is responsible for caching the checksums computed from

local file system. Because it's also used for dependency verification

writing and checking, this cache uses the existing infrastructure which

makes sure that if a file is updated locally, we expire the entry in

the cache.

This is done because there are lots of places in the code where we

used the legacy `HashUtil` class, which has no caching whatsoever.

It's, however, quite common to have a build which generates sha1

checksums multiple times for the same file. For example, during

publication.

  1. … 103 more files in changeset.
Avoid eager creation of `ResolveIvyFactory`

The `ResolveIvyFactory` instance was created too eagerly. In general,

this isn't a problem because most builds will eventually resolve

dependencies. But there are cases, like when calling `help`, when this

is not the case.

The previous code was assuming that a factory would always be created,

and by side effect moved the creation of the factory to an earlier

phase during build initialization, triggering the creation of the file

access journal.

This is no longer the case: we only create the dependency verification

parameter override eagerly, and configure the build to shut it down

at the end of the build.

  1. … 4 more files in changeset.
Avoid eager creation of `ResolveIvyFactory`

The `ResolveIvyFactory` instance was created too eagerly. In general,

this isn't a problem because most builds will eventually resolve

dependencies. But there are cases, like when calling `help`, when this

is not the case.

The previous code was assuming that a factory would always be created,

and by side effect moved the creation of the factory to an earlier

phase during build initialization, triggering the creation of the file

access journal.

This is no longer the case: we only create the dependency verification

parameter override eagerly, and configure the build to shut it down

at the end of the build.

  1. … 4 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.
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.
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.
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.
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.
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.
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.
Move class generation and instantation infrastructure from core to modelCore project.

  1. … 90 more files in changeset.
Fix tests

  1. … 2 more files in changeset.
Allow filtering content of a repository based on the configuration name and attributes

This effectively adds the configuration name, as well as its attributes, to the context

details, so a rule can decide to resolve differently.

  1. … 6 more files in changeset.
Make comparison of `ModuleComponentAtRepositoryKey` faster

to mitigate small performance regression due to the isolation

of component metadata rules.

  1. … 6 more files in changeset.
Make comparison of `ModuleComponentAtRepositoryKey` faster

to mitigate small performance regression due to the isolation

of component metadata rules.

  1. … 6 more files in changeset.
Revert per-project caches as it has a very large impact on performance

  1. … 4 more files in changeset.
Revert per-project caches as it has a very large impact on performance

  1. … 4 more files in changeset.
Make the in-memory dependency metadata caches per project

  1. … 5 more files in changeset.
Make the in-memory dependency metadata caches per project

  1. … 5 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

  1. … 64 more files in changeset.
Always provide a VersionSelector when resolving dependency -> component id

  1. … 11 more files in changeset.
Track file access in AbstractCachedIndex

Instead of tracking access in DefaultCacheAwareExternalResourceAccessor

and CachingModuleComponentRepository this is now done in

AbstractCachedIndex which ensures it's done always when reading from

indexes of CachedItems and only does so when not already present in an

in-memory cache from a previous lookup.

  1. … 39 more files in changeset.
Enable service injection in ComponentMetadataRule

This is currently limited to the RepositoryResourceAccessor and is not

available for flat dir repositories.

Fixes #5565

  1. … 43 more files in changeset.
Mark cached files accessed when resolved via index

Both CachingModuleComponentRepository and

DefaultCacheAwareExternalResourceAccessor use an index to resolve

cached artifacts. Both now notify the underlying FileStore which now

implements FileAccessTracker. The new AccessTrackingFileStore interface

combines both interfaces so the GroupedAndNamedUniqueFileStore

subclasses (ArtifactIdentifierFileStore and ExternalResourceFileStore)

can be injected into dependent components.

  1. … 32 more files in changeset.
Introduce `ComponentMetadataSupplierRuleExecutor`

This gives us better abilities to unit test the behavior of this specific

rule executor.

  1. … 16 more files in changeset.
Introduce `ComponentMetadataSupplierRuleExecutor`

This gives us better abilities to unit test the behavior of this specific

rule executor.

  1. … 16 more files in changeset.
Enforce isolation of ComponentMetadataRule

This means that passed in parameters must be snapshotable as defined by

the ValueSnapshotter

Added support for Attribute to ValueSnapshotter

  1. … 53 more files in changeset.