[Lipen]

JacoDB dependencies are resolved from GitHub Packages (org.jacodb) with property-first local credentials and GitHub token access in CI. The pin is 20261012+1e1c0312, published from producer commit 1e1c0312c9141322c95a413083918e901742dc12.

Prerequisite: JacoDB #432 restricts production and published fixtures to Java 8 APIs and declares the matching Gradle JVM metadata. This prevents a snapshot compiled on a newer JDK from linking collection methods unavailable to Java 11 consumers. The producer PR is still open; this dependency uses its explicitly published snapshot.

CI retains current main's native TypeScript frontend jobs and grants package reads without removing the lint job's SARIF upload permission.

Validation:

• JacoDB publishing run: SUCCESS on JDK21; all eight module publication tasks completed.
• Local producer publication build on JDK23 completed under the root's limited serial gate.
• Local Java11 artifact consumer gate: 32 passed, 2 skipped, zero failures across JavaAnalysisApi, TaintFlowFunctions and ConcreteExecutor regressions (local publication/substitution).
• Actual authenticated GitHub Packages resolution in USVM CI remains pending; the local consumer pass does not establish cross-repository package authorization.

[Saloed]

Please, review jvm test issues

[Saloed]

Do we really need jacodb repo in all projects?

[Lipen]

Do we need JitPack repo in all projects? Same thing. So it does not hurt us to add jacodb GPR in all sub-projects using the convention plugin.

We could also make the GPR setup a separate convention plugin (I have a working solution), but it looks more weird than this Project extension function.

[Lipen]

Please, review jvm test issues

I can reproduce it locally. Also, if I build jacodb to the local maven repo using JDK 8, and then use those artifacts in USVM (running with jdk 11, since usvm requires it), tests pass. Thus, it is the issue related to the built artifacts. I already have heard the rumors that such situations might happen, and that "compiling with java 8 compatibility" is no the same as "compiling with JDK 8 directly", but never seen this in reality.

@Saloed What is the action here? Again just hide the problem by using jdk 8 for building jacodb on CI?

[Lipen]

He-he, similar issue: javalin/javalin#2117

[Lipen]

Using options.release = 8 in jacodb with jdk21 locally produces artifacts that pass USVM tests. So probably this is a solution on the jacodb side: UnitTestBot/jacodb#337