|
|
|
 |
- last updated a few seconds ago
Tuesday 03 Dec
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.
-
-
… 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.
-
-
… 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.
-
-
… 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.
-
-
… 103 more files in
changeset.
Thursday 21 Nov
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.
-
-
… 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.
-
-
… 4 more files in
changeset.
Tuesday 19 Nov
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
-
-
… 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
-
-
… 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
-
-
… 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
-
-
… 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
-
-
… 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
-
-
… 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
-
-
… 32 more files in
changeset.
Wednesday 26 Dec 2018
Move class generation and instantation infrastructure from core to modelCore project.
-
-
… 90 more files in
changeset.
Friday 26 Oct 2018
-
-
… 2 more files in
changeset.
Wednesday 24 Oct 2018
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.
-
-
… 6 more files in
changeset.
Friday 19 Oct 2018
Make comparison of `ModuleComponentAtRepositoryKey` faster to mitigate small performance regression due to the isolation of component metadata rules.
-
-
… 6 more files in
changeset.
Make comparison of `ModuleComponentAtRepositoryKey` faster to mitigate small performance regression due to the isolation of component metadata rules.
-
-
… 6 more files in
changeset.
Wednesday 17 Oct 2018
Revert per-project caches as it has a very large impact on performance
-
-
… 4 more files in
changeset.
Revert per-project caches as it has a very large impact on performance
-
-
… 4 more files in
changeset.
Monday 15 Oct 2018
Make the in-memory dependency metadata caches per project
-
-
… 5 more files in
changeset.
Make the in-memory dependency metadata caches per project
-
-
… 5 more files in
changeset.
Monday 08 Oct 2018
Split off value snapshotting and attributes related methods of TestUtil
-
-
… 64 more files in
changeset.
Monday 17 Sep 2018
Always provide a VersionSelector when resolving dependency -> component id
-
-
… 11 more files in
changeset.
Friday 08 Jun 2018
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.
-
-
… 39 more files in
changeset.
Wednesday 30 May 2018
Enable service injection in ComponentMetadataRule This is currently limited to the RepositoryResourceAccessor and is not available for flat dir repositories. Fixes #5565
-
-
… 43 more files in
changeset.
Friday 25 May 2018
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.
-
-
… 32 more files in
changeset.
Thursday 17 May 2018
Introduce `ComponentMetadataSupplierRuleExecutor` This gives us better abilities to unit test the behavior of this specific rule executor.
-
-
… 16 more files in
changeset.
Introduce `ComponentMetadataSupplierRuleExecutor` This gives us better abilities to unit test the behavior of this specific rule executor.
-
-
… 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
-
-
… 53 more files in
changeset.
|
