You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
verification-metadata.xml should have a consistent sort order of the entries.
For instance, Gradle should sort entries when running --write-verification-metadata ..., and Gradle could print a warning (or even error) when it detects unordered entries when reading the file (it is as cheap as O(N)).
Current Behavior
Newly added entries (e.g. after --write-verification-metadata sha256) are appended to the tail of the file, which causes inconsistent behavior, and it is prone to cause maintenance problems.
Context
"Pull request maintenance". If multiple pull requests add different dependencies, then (in the current scheme) they both will add lines to the end of the file, thus it will cause merge conflicts. Note: even though the conflict is trivial to resolve, it is a true merge conflict, and GitHub / Travis stops building the PR until the conflict is resolved.
On the other hand, if the file is always sorted, then the likelihood of the conflict is lower.
"Maintenance of multiple versions". If multiple versions of the same dependency are included in the verification metadata, then it would make sense to have them side by side.
For instance, it would be easier to notice "outdated" versions and remove them. The current approach of appending entries does not make it clear which artifacts have multiple known checksums.
"The lack of tooling" to support consistent formatting typically causes back-and-forth conversation of the code style to use. People might add entries to wrong locations even by mistake (e.g. by failing to sort properly).
There's a well-known case "Harry Potter and the Order of the Imports", and typically it is resolved by sorting imports alphabetically. For instance: https://google.github.io/styleguide/javaguide.html#s3.3.3-import-ordering-and-spacing
The text was updated successfully, but these errors were encountered:
Expected Behavior
verification-metadata.xml should have a consistent sort order of the entries.
For instance, Gradle should sort entries when running
--write-verification-metadata ...
, and Gradle could print a warning (or even error) when it detects unordered entries when reading the file (it is as cheap as O(N)).Current Behavior
Newly added entries (e.g. after
--write-verification-metadata sha256
) are appended to the tail of the file, which causes inconsistent behavior, and it is prone to cause maintenance problems.Context
"Pull request maintenance". If multiple pull requests add different dependencies, then (in the current scheme) they both will add lines to the end of the file, thus it will cause merge conflicts. Note: even though the conflict is trivial to resolve, it is a true merge conflict, and GitHub / Travis stops building the PR until the conflict is resolved.
On the other hand, if the file is always sorted, then the likelihood of the conflict is lower.
"Maintenance of multiple versions". If multiple versions of the same dependency are included in the verification metadata, then it would make sense to have them side by side.
For instance, it would be easier to notice "outdated" versions and remove them. The current approach of appending entries does not make it clear which artifacts have multiple known checksums.
"The lack of tooling" to support consistent formatting typically causes back-and-forth conversation of the code style to use. People might add entries to wrong locations even by mistake (e.g. by failing to sort properly).
There's a well-known case "Harry Potter and the Order of the Imports", and typically it is resolved by sorting imports alphabetically. For instance: https://google.github.io/styleguide/javaguide.html#s3.3.3-import-ordering-and-spacing
The text was updated successfully, but these errors were encountered: