Repository navigation
scalasem: read jar coordinates from Ivy and Gradle cache paths - #32
Merged
Merged
Conversation
jarCoordinate understood only the Maven repository layout, so the report's module classpath left out jars sbt resolved from the Ivy local repository, such as publishLocal dependencies, along with jars from the Ivy and Gradle caches. Unmanaged jars carry no coordinate and stay out, as the report schema requires group, artifact and version.
prabhu
added
bug
prabhu
enabled auto-merge
October 30, 2026 04:07
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.
The report records each module's dependency classpath with Maven coordinates, and
jarCoordinatecould read those coordinates only from a Maven repository layout. A jar that sbt resolved from anywhere else had no group, artifact and version, and the report drops classpath entries without them. After #31, atom's classpath includes the chen modules it gets throughpublishLocal, at paths such as~/.ivy2/local/io.appthreat/c2cpg_3/4.0.0/jars/c2cpg_3.jar, but the report still left every one of them out. cdxgen relies on this classpath to decide which component a symbol belongs to, so atom's imports ofio.shiftleft.codepropertygraphandio.shiftleft.semanticcpgcould not be attributed to cpg2 or semanticcpg.jarCoordinatenow also reads the layouts in which the group is a single dotted directory:<org>/<artifact>/<version>/jars/<artifact>.jar, including thescala_<v>/sbt_<v>directories sbt plugins add before the version<org>/<artifact>/jars/<artifact>-<version>.jar, and itsbundlesdirectoryfiles-2.1/<group>/<artifact>/<version>/<sha1>/<file>.jarUnmanaged jars, such as the
lib/org.eclipse.cdt.corejar in atom, have no coordinates, so they stay out of the report.Results:
io.appthreat, the cpg2 jars at 3.0.10 and the odb2 jars at 3.0.9. Facts and diagnostics are unchanged.cdxgen -t scala --evidence --profile researchfinds 1856 occurrences, up from 636. cpg2 and semanticcpg get their occurrences, and all 22 call stacks resolve to the component they end in.The new cases in
test-fixtures/scalasem-engine.jscover each layout.npm testandnpm run test:scalapass, and Prettier reports no changes.This change goes out with 1.10.6, the version
mainalready carries; it has not been tagged yet.