fix(java): map legacy Jackson 1.x (-asl) artifacts to org.codehaus.jackson

[ankit090701]

Closes #4598

What

jackson-mapper-asl, jackson-core-asl, and their sibling artifacts (jackson-jaxrs, jackson-xc, jackson-smile) — the pre-2.x "Jackson 1.x" / "jackson-asl" family — predate the convention of embedding META-INF/maven/.../pom.properties in the jar (they were built with Ant, before ~2014). I confirmed this directly: jackson-mapper-asl-1.9.13.jar genuinely has no META-INF/maven/ directory at all.

With no POM metadata to read, groupIDFromJavaMetadata falls through its precedence chain (POM properties → POM project → known package list → manifest) to the known-package-list lookup, which currently has no entry for these artifacts, so it falls through further and syft ends up using the artifact name itself as the group ID:

pkg:maven/jackson-mapper-asl/jackson-mapper-asl@1.9.13

instead of the correct

pkg:maven/org.codehaus.jackson/jackson-mapper-asl@1.9.13

I verified the correct group ID for all five artifacts directly against their published POMs on Maven Central (e.g. https://repo1.maven.org/maven2/org/codehaus/jackson/jackson-mapper-asl/1.9.13/jackson-mapper-asl-1.9.13.pom) — all five have <groupId>org.codehaus.jackson</groupId>.

Why it matters

Because the generated purl's namespace doesn't match the vulnerability database's namespace for these packages, this causes false negatives in downstream scanning. Grype's DB correctly has, e.g., GHSA-c27h-mcmw-48hv (CVE-2019-10202) scoped to org.codehaus.jackson:jackson-mapper-asl, but can't match it against syft's pkg:maven/jackson-mapper-asl/jackson-mapper-asl@1.9.13 output.

Fix

Add the five artifacts to DefaultArtifactIDToGroupID, the same known-package-list fallback already used for other jars with incomplete metadata (e.g. the existing ant-*, spring-ldap* entries — this map is shared by both purl and CPE generation, so both benefit).

Testing

Added two cases to Test_groupIDFromJavaMetadata in syft/pkg/cataloger/java/package_url_test.go (following the existing spring-ldap regression-test pattern for issue #4030), asserting groupIDFromJavaMetadata("jackson-mapper-asl", pkg.JavaArchive{}) and groupIDFromJavaMetadata("jackson-core-asl", pkg.JavaArchive{}) return org.codehaus.jackson with no other metadata present.

I verified the regression test actually catches the bug: reverting only the map change (git stash on java_groupid_map.go, keeping the new tests) makes both new cases fail with expected: "org.codehaus.jackson", actual: "", exactly reproducing the reported behavior. Restoring the fix makes them pass.

go vet is clean and go test ./syft/pkg/cataloger/java/... ./syft/pkg/cataloger/internal/cpegenerate/... passes for everything my change touches. (Note: on this Windows dev environment, TestSearchMavenForLicenses/TestParseJar/etc. in syft/pkg/cataloger/java and Test_processCPEList in dictionary/index-generator fail identically on a clean, unmodified main checkout — pre-existing CRLF/network-dependent environmental issues unrelated to this change, not introduced by it.)