Repository navigation
Read Maven versions from maven-metadata.xml - #114
Conversation
FetchPackage, FetchVersions and FetchMaintainers asked search.maven.org first and only read maven-metadata.xml when the search failed. The search only knows Central, so a custom base URL still listed Central's versions, every lookup spent a rate-limited request, and FetchVersions stopped at 200 versions. All three now read maven-metadata.xml from the configured repository. FetchPackage sets LatestVersion from <release> or <latest>. Versions come newest first as before, but without PublishedAt, since the metadata has no per-version dates. Fixes git-pkgs#99
andrew
left a comment
There was a problem hiding this comment.
Reading the version list from the configured repository's maven-metadata.xml is right, but dropping the search API also drops every Maven publish date. git-pkgs/enrichment copies PublishedAt from FetchVersions (registries.go:92), and in direct mode the git-pkgs CLI's freshness skips versions with no date and outdated --at finds nothing, so Maven dependencies would get no results from either.
When the base URL is Central (DefaultURL), please still query the search API (core=gav, rows=200) after reading the metadata and copy each doc's timestamp onto the version with the same number. The list itself always comes from maven-metadata.xml, and a failed or empty search just leaves the dates out. For a custom base URL, skip the search entirely. Please add a test for each case: Central with dates filled in for the versions search returns, a search failure that still returns every version, and a custom base URL that never calls search.
Reading versions only from maven-metadata.xml dropped every publish date, which enrichment copies and the CLI's freshness and outdated --at rely on. For Central, FetchVersions now also asks the search API (core=gav, 200 rows) and copies each doc's timestamp onto the version with the same number. The list still comes from the metadata, a failed or empty search only leaves the dates out, and other repositories skip the search.
The Maven client asked
search.maven.orgbefore the configured repository, so a custom base URL still listed Central's versions, every lookup spent a rate-limited search request, andFetchVersionsstopped at 200 versions.FetchPackage,FetchVersionsandFetchMaintainersnow readmaven-metadata.xmlfrom the configured repository.FetchPackagesetsLatestVersionfrom<release>, then<latest>, soFetchLatestVersionstill finds the right version without timestamps.FetchVersionsreturns every listed version, newest first as before. For Maven Central it also asks the search API (core=gav,rows=200) and copies each doc's timestamp onto the version with the same number, so enrichment and the CLI keep their publish dates. A failed or empty search only leaves the dates out. Other repositories skip the search and get no dates.FetchMaintainersreads the POM of the release version.Checked against Central:
net.bytebuddy:byte-buddynow returns all 329 versions.Tests cover Central with dates for the versions search returns, a search failure that still returns every version, and a custom base URL that never calls search.
Fixes #99