|
|
 |
- last updated a few seconds ago
Saturday 30 Nov
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.
-
-
… 39 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.
-
-
… 38 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.
-
-
… 39 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.
-
-
… 39 more files in
changeset.
Wednesday 27 Nov
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.
-
-
… 64 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.
-
-
… 62 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.
-
-
… 64 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.
-
-
… 64 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.
-
-
… 63 more files in
changeset.
Wednesday 09 Oct
Revert "Revert "Merge branch 'release'"" This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2. This restores the merge attempt from earlier.
-
-
… 66 more files in
changeset.
Tuesday 08 Oct
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.
-
-
… 66 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
-
-
… 16 more files in
changeset.
Changes in Gradle Module Metadata generation 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.
-
-
… 16 more files in
changeset.
Tuesday 11 Jun
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.
-
-
… 30 more files in
changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.
-
-
… 32 more files in
changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.
-
-
… 32 more files in
changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.
-
-
… 32 more files in
changeset.
Monday 29 Apr
Remove unused legacy code that looks for variants by name
-
-
… 2 more files in
changeset.
Monday 08 Oct 2018
Split off value snapshotting and attributes related methods of TestUtil
-
-
… 64 more files in
changeset.
Tuesday 04 Sep 2018
Use an `ImmutableSet` to represent the configuration hierarchy ImmutableSets are ordered and optimized for lookups. We happen to call `contains` a lot on hierarchies, so using a `Set` should optimize things a little.
-
-
… 31 more files in
changeset.
Monday 09 Jul 2018
Rename method to better indicate meaning The hash value returned by getOriginalContentHash() is the one from the metadata parsed from a repository. It does not reflect any of the potential mutations that happened to it at later stages. The new name indicates this better.
-
-
… 9 more files in
changeset.
Friday 08 Jun 2018
Normalize `ModuleIdentifier` This commit reworks the `ComponentModuleIdentifier`/`ComponentModuleSelector`/`ModuleVersionSelector` classes to use `ModuleIdentifier` under the hood, instead of storing denormalized strings. This has the advantage that we can reduce the use of the module identifier factory, which is called very often during dependency resolution. Sharing instances reduces the need for conversions, and makes comparisons faster.
-
-
… 164 more files in
changeset.
Friday 16 Mar 2018
Rename id accessors for consistency Use `ComponentIdentifier getId()` Use `ModuleVersionIdentifier getModuleVersionId()`
-
-
… 67 more files in
changeset.
Wednesday 20 Dec 2017
Initial implementation of component metadata rules allowing modification of variant attributes This commit introduces metadata rules that support modification of variant attributes. Variant attributes are specific to each variant and can be found in module metadata. Those are NOT component level attributes, which could be used during dependency resolution. This will be added in a subsequent commit.
-
-
… 49 more files in
changeset.
Create all mutable Ivy module resolve metadata through factory This will simplify the injection of services through the factory, when we will need the immutable attributes factory to be pushed to resolve metadata.
-
-
… 26 more files in
changeset.
-
-
… 7 more files in
changeset.
Tuesday 19 Dec 2017
Rework `DefaultMutableIvyModuleResolveMetadata` constructors for consistency Introduce constants where it makes sense and use consistent order of parameters.
-
-
… 5 more files in
changeset.
Wednesday 22 Nov 2017
Remove ability update Excludes on metadata This functionality wasn't required, and was adding complexity.
-
-
… 6 more files in
changeset.
Remove method that forces all ConfigurationMetadata to be instantiated up-front This method is only used in tests, and makes it more difficult to build configuration instances on-demand.
-
-
… 2 more files in
changeset.
Construct ConfigurationMetadata instances when creating immutable resolve metadata Previously, the mutable types would construct ConfigurationMetadata instances, and invalidate them on change to the inputs. With this change, creating an (immutable) ConfigurationMetadata instance happens when constructing an immutable ModuleComponentResolveMetadata.
-
-
… 10 more files in
changeset.
|