…gnature

Add new import schema with path, is_static, and is_wildcard fields

…lizers

feat: emit per-variable field initializers in field declarations

…arity

The GraalVM native binary diverged from `java -jar`: empty callee
signatures/return types and missing CRUD detection. Root cause is that
in a native image `Class.forName` resolves a class but
`getDeclaredMethods()`/`getDeclaredFields()` return empty for
unregistered types, so a `ReflectionTypeSolver` silently "resolves"
every lookup while enumerating zero members.

Add `JmodTypeSolver`, a reflection-free JavaParser `TypeSolver` that
reads `.class` bytecode straight out of zip archives (the JDK's `.jmod`
files and the project's downloaded dependency jars) via a custom
`javassist.ClassPath` backed by `ZipFile`. This works identically in
the JVM and the native image. Wire it ahead of `ReflectionTypeSolver`
in all three extract paths; keep `JarTypeSolver` only as a JVM fallback
when no jmods are present.

Supporting changes:
- ScopeUtils.resolveJmodsDir() made public and honors a
  CODEANALYZER_JMODS_DIR override so the packaged distribution can point
  at bundled jmods instead of a host JAVA_HOME.
- VersionProvider reads the version from an embedded resource (no JAR
  manifest exists at runtime in a native image).
- Declare the native-image-config dir as a nativeCompile input so edits
  to reflect-/resource-config reliably trigger a rebuild.
- Regenerate targeted reflect-/resource-config.json.

Verified byte-identical native vs `java -jar` output (Anonymous-UUIDs
masked) across call-graph-test (L2), record-class-test, init-blocks-test,
plantsbywebsphere (CRUD 38=38), and daytrader8.

…ajv)

Adds a hatchling-based Python distribution under pypi/ that wraps the
prebuilt, JVM-free GraalVM native binary so codeanalyzer is installable
with a plain `pip install codeanalyzer-java` (console command `codajv`),
no JDK/GraalVM or build step required.

- pyproject.toml: dist name codeanalyzer-java; version read from
  ../gradle.properties via a custom metadata hook so the wheel stays in
  lockstep with the binary.
- hatch_build.py: build hook force-includes the native binary plus the
  JDK jmods the binary needs at runtime (WALA primordial scope +
  JmodTypeSolver), marks the wheel non-purelib, and stamps a concrete
  py3-none-<platform> tag so pip resolves the right artifact per
  OS/arch instead of a universal wheel.
- codeanalyzer_java/__main__.py: locates the bundled binary, points
  CODEANALYZER_JMODS_DIR at the bundled jmods, and execs the binary
  (subprocess on Windows); falls back to the gradle output + JAVA_HOME
  in a source checkout.
- Bundle 79/83 jmods to fit under PyPI's 100 MB limit, dropping only
  jdk.localedata/compiler/internal.vm.compiler/hotspot.agent (locale
  data + javac/Graal/SA internals that static analysis never needs).
  CODEANALYZER_BUNDLE_ALL_JMODS=1 bundles all 83.

Verified: installed wheel runs JVM-free and is byte-identical to
`java -jar` (full jmods) across call-graph-test, record-class-test,
init-blocks-test, plantsbywebsphere (CRUD 38=38), and daytrader8.

Build platform-tagged, impure wheels (each bundling a GraalVM native binary
plus the JDK jmods it needs at runtime) across manylinux, musllinux, macOS,
and Windows, then publish via OIDC Trusted Publishing.

- release-pypi.yml: build-wheels matrix, sdist, GitHub Release on tag, and
  publish-pypi/publish-testpypi jobs gated on tag push or manual dispatch.
- Linux legs build inside manylinux_2_28 containers so wheel tags are correct
  by construction; musllinux legs build a fully-static --libc=musl binary.
- smoke-test.sh runs each wheel JVM-free (codajv --version plus a level-1
  source analysis that exercises the bundled jmods).
- setup-musl.sh provisions the musl toolchain + static zlib (experimental).
- build.gradle: emit a static musl binary when CODEANALYZER_NATIVE_MUSL=true.
- hatch_build.py: honor CODEANALYZER_WHEEL_PLATFORM to stamp the exact tag.

`codajv -s <source>` crashed with ExceptionInInitializerError/NPE: analyze()
called BuildProject.cleanLibraryDependencies() unconditionally, and merely
referencing BuildProject runs its static initializer, which resolves a
gradle/maven command via new File(projectRootPom) — null in source mode.
Guard the cleanup so it runs only in project mode, where dependencies are
actually downloaded. Caught by the new PyPI release smoke test.

GitHub retired the Intel macos-13 hosted runners, so the macos-x86_64
leg sat queued forever and hung the whole release run. Rebuild it on a
macos-14 (Apple Silicon) runner: install an x86_64 GraalVM and run
native-image under Rosetta 2, which emits an x86_64 binary and x86_64
jmods (native-image has no true cross-target).

Drop the Windows wheel entirely. Its build also failed (hatch_build.py
looked for 'codeanalyzer' but GraalVM emits 'codeanalyzer.exe' on
Windows), and Windows native-image support isn't worth maintaining here.
Removes the windows matrix leg, the MSVC setup step, and the now-unused
.exe binary fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…6-drop-windows

ci: cross-build macOS x86_64 on Apple Silicon; drop Windows

The musllinux legs failed with 'Failed to connect to musl.cc port 443:
Connection timed out'. musl.cc is chronically flaky. Download the musl
toolchain from a GitHub-hosted mirror (musl-cc/musl.cc) first, falling
back to musl.cc; do the same for zlib (madler/zlib release, then
zlib.net, then zlib.net/fossils). Add curl --retry with a connect
timeout. Avoids --retry-all-errors since the manylinux_2_28 container's
curl 7.61 predates it.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…6-drop-windows

ci: make musl toolchain/zlib downloads resilient to musl.cc outages

Two follow-ups surfaced by the re-tagged v2.3.7 run:

- musl native link failed with 'read-only segment has dynamic
  relocations' on .svm_heap. The musl.cc gcc 11 toolchain defaults to
  static-PIE, which GraalVM's image heap can't satisfy. Add
  -H:NativeLinkerOption=-no-pie for the musl build to force a non-PIE
  static executable. (The earlier musl.cc download fix worked; this is
  the next error it exposed.)

- macOS x86_64 wheel built fine but its smoke test failed: the runner's
  arm64 Python can't install an x86_64-tagged wheel. Run that leg's
  smoke test under Rosetta via the universal /usr/bin/python3 so the
  venv, pip install, and bundled binary are all x86_64.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…os-smoke

ci: fix musl static-PIE link + macOS x86_64 cross-wheel smoke test

The musl wheels build cleanly now but couldn't be validated: a musllinux
wheel can't be pip-installed on the glibc manylinux build host, and the
build runs inside a container so docker-in-docker isn't available.

Add a stage-then-promote flow:
- build-wheels uploads musl wheels under a 'musl-staging-*' artifact and
  skips the in-job smoke (it physically can't run on glibc).
- A new 'smoke-musl' job runs per-arch on native host runners, installs
  and exercises each wheel inside a python:3.12-alpine (musl) container
  via docker, and only on success promotes it to the publishable
  'wheel-*' name. So an unverified musl wheel never reaches PyPI.
- github-release / publish-pypi / publish-testpypi now pull 'wheel-*'
  (+ sdist) only — never the staging artifacts — and wait for smoke-musl
  via needs, but are gated solely on the essential build jobs (always()
  + result checks) so the experimental musl leg can never block release.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

ci: smoke-test musl wheels in Alpine, then publish them