feat(java): add support for palantir gradle-consistent-versions versions.lock lockfiles - #5218
Open
CAOShurong wants to merge 1 commit into
Open
Conversation
…ons.lock lockfiles Signed-off-by: Shurong Cao <CAOShurong@users.noreply.github.com>
CAOShurong
force-pushed
the
codex/5176-gradle-consistent-versions-lockfile
branch
from
August 23, 2026 17:12
06d9d11 to
791062f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of changes
Adds static parsing support for Palantir's gradle-consistent-versions lockfile (
versions.lock), as requested in #5176.parseGradleConsistentVersionsLockfilein 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.java-gradle-lockfile-catalogernow also globs**/versions.lock, so bothgradle.lockfileandversions.lockare discovered by the same cataloger (no new cataloger name or task registration needed).JavaArchivemetadata withPomProject,pkg:maven/...PURLs).Example
Input:
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.lockfilesupport.Fixes #5176
How I tested it
Locally on Windows / go1.26.6:
Test_parseGradleConsistentVersionsLockfileagainst a fixture modeled on the example from the issue (multi-constraint lines, comments, blank lines): PASSTest_parserGradleLockfilestill passes (no behavior change forgradle.lockfile)syft scan dir:. --select-catalogers +java-gradle-lockfile-cataloger -o jsonagainst a directory containing onlyversions.lock— all 3 fixture packages discovered with correct purls; a mixed directory containing bothgradle.lockfileandversions.lockyields the union of both parsers with correct evidence locationsgo vet ./syft/pkg/cataloger/java/clean; the remaining failures ingo test ./syft/pkg/cataloger/java/...on this machine are pre-existing environment failures (tests requiringmake) identical to those on unmodified mainThanks for considering!