Copilot commented on code in PR #2135:
URL: https://github.com/apache/maven-resolver/pull/2135#discussion_r3993796097
##########
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/FileTrustedChecksumsSourceSupport.java:
##########
@@ -193,21 +183,24 @@ protected Path getBasedir(
}
/**
- * Returns repository key to be used on file system layout.
+ * Returns repository keys to be used on file system layout. Always
returns a list with at least one element.
+ * Elements are sorted from "most specific" to "least specific" keys.
*
* @since 2.0.14
*/
- protected String repositoryKey(RepositorySystemSession session,
ArtifactRepository artifactRepository) {
+ protected List<String> repositoryKey(RepositorySystemSession session,
ArtifactRepository artifactRepository) {
+ ArrayList<String> keys = new ArrayList<>();
if (artifactRepository instanceof RemoteRepository) {
- return repositoryKeyFunctionFactory
- .repositoryKeyFunction(
- FileTrustedChecksumsSourceSupport.class,
- session,
- DEFAULT_REPOSITORY_KEY_FUNCTION,
- CONFIG_PROP_REPOSITORY_KEY_FUNCTION)
- .apply((RemoteRepository) artifactRepository, null);
+ RemoteRepository rr = (RemoteRepository) artifactRepository;
+ keys.add(repositoryKeyFunctionFactory
Review Comment:
The previously documented
`aether.trustedChecksumsSource.repositoryKeyFunction` option (introduced in
2.0.14) is removed and no longer consulted. Existing installations that
selected a non-default key will silently look in different checksum locations,
so their trusted checksums stop being found after upgrading. Preserve a
deprecated compatibility alias or provide an explicit migration path instead of
silently ignoring the setting.
##########
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/SummaryFileTrustedChecksumsSource.java:
##########
@@ -175,8 +171,8 @@ protected Map<String, String> doGetTrustedArtifactChecksums(
List<ChecksumAlgorithmFactory> checksumAlgorithmFactories) {
return doGetTrustedPathChecksums(
session,
- localPathComposer.getPathForArtifact(artifact, false),
- artifactRepository,
+ repositoryKey(session, artifactRepository).subList(0, 1),
Review Comment:
Artifact summary files are now written under the first (tracking) repository
key, but this lookup deliberately restricts `repoKeys` to that same first
entry. That drops the system-key fallback introduced by
`FileTrustedChecksumsSourceSupport`, so a checksum file created before this
change as `checksums-<nid>.sha1` is ignored under the default `nid_hurl`
tracking key and `failIfMissing` can reject an otherwise trusted artifact.
Probe the full key list here, in the same tracking-then-system order used for
metadata.
##########
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/filter/RemoteRepositoryFilterSourceSupport.java:
##########
@@ -111,18 +102,22 @@ protected RemoteRepository normalizeRemoteRepository(
}
/**
- * Returns repository key to be used on file system layout.
+ * Returns repository keys to be used on file system layout for user
provided files. They are ordered as
+ * "most specific" (using {@link
RepositoryKeyFunctionFactory#trackingRepositoryKeyFunction(RepositorySystemSession)})
+ * to simple "id based" one. This allows user to keep using plain ID, but
also to provide very narrowly targeted
+ * input files, when needed.
*
* @since 2.0.14
*/
- protected String repositoryKey(RepositorySystemSession session,
RemoteRepository repository) {
- return repositoryKeyFunctionFactory
- .repositoryKeyFunction(
- RemoteRepositoryFilterSourceSupport.class,
- session,
- DEFAULT_REPOSITORY_KEY_FUNCTION,
- CONFIG_PROP_REPOSITORY_KEY_FUNCTION)
- .apply(repository, null);
+ protected List<String> repositoryKeys(RepositorySystemSession session,
RemoteRepository repository) {
+ ArrayList<String> keys = new ArrayList<>();
+ keys.add(repositoryKeyFunctionFactory
+ .trackingRepositoryKeyFunction(session)
+ .apply(repository, null));
Review Comment:
The previously documented
`aether.remoteRepositoryFilter.repositoryKeyFunction` option (introduced in
2.0.14) is removed and no longer consulted. A user who selected a non-default
key such as `ngurk` will silently fall back to the global tracking/system keys,
so existing filter files become unreachable after upgrading. Preserve a
deprecated compatibility alias or provide an explicit migration path instead of
silently ignoring the setting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
