Skip to content

feat(java): add support for palantir gradle-consistent-versions versions.lock lockfiles - #5218

Open
CAOShurong wants to merge 1 commit into
anchore:mainfrom
CAOShurong:codex/5176-gradle-consistent-versions-lockfile
Open

feat(java): add support for palantir gradle-consistent-versions versions.lock lockfiles#5218
CAOShurong wants to merge 1 commit into
anchore:mainfrom
CAOShurong:codex/5176-gradle-consistent-versions-lockfile

Conversation

@CAOShurong

Copy link
Copy Markdown
Contributor

Summary of changes

Adds static parsing support for Palantir's gradle-consistent-versions lockfile (versions.lock), as requested in #5176.

  • New parser parseGradleConsistentVersionsLockfile in the java cataloger package: each line of the form <group>:<artifact>:<version> (<N> constraints: <hash>) is parsed as a Maven-coordinate Java package; the constraint/hash suffix, empty lines and comments are ignored.
  • The existing java-gradle-lockfile-cataloger now also globs **/versions.lock, so both gradle.lockfile and versions.lock are discovered by the same cataloger (no new cataloger name or task registration needed).
  • Packages are emitted with the same shape as the existing gradle lockfile parser (JavaArchive metadata with PomProject, pkg:maven/... PURLs).

Example

Input:

com.fasterxml.jackson.core:jackson-annotations:2.12.3 (3 constraints: f311b512)
com.google.guava:guava:30.1.1-jre (12 constraints: b290ec5e)

Output (syft scan dir:. -o json):

[
  {"name": "jackson-annotations", "version": "2.12.3", "type": "java-archive", "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-annotations@2.12.3"},
  {"name": "guava", "version": "30.1.1-jre", "type": "java-archive", "purl": "pkg:maven/com.google.guava/guava@30.1.1-jre"}
]

This enables JVM-less, offline SBOM generation for enterprise Gradle projects that pin dependencies with the Palantir plugin, complementing the existing native gradle.lockfile support.

Fixes #5176

How I tested it

Locally on Windows / go1.26.6:

  • new unit test Test_parseGradleConsistentVersionsLockfile against a fixture modeled on the example from the issue (multi-constraint lines, comments, blank lines): PASS
  • existing Test_parserGradleLockfile still passes (no behavior change for gradle.lockfile)
  • end-to-end: built syft from this branch and ran syft scan dir:. --select-catalogers +java-gradle-lockfile-cataloger -o json against a directory containing only versions.lock — all 3 fixture packages discovered with correct purls; a mixed directory containing both gradle.lockfile and versions.lock yields the union of both parsers with correct evidence locations
  • go vet ./syft/pkg/cataloger/java/ clean; the remaining failures in go test ./syft/pkg/cataloger/java/... on this machine are pre-existing environment failures (tests requiring make) identical to those on unmodified main

Thanks for considering!

…ons.lock lockfiles

Signed-off-by: Shurong Cao <CAOShurong@users.noreply.github.com>
@CAOShurong
CAOShurong force-pushed the codex/5176-gradle-consistent-versions-lockfile branch from 06d9d11 to 791062f Compare August 23, 2026 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support Palantir's gradle-consistent-versions lockfile (versions.lock)

1 participant