New cache strategy: two-path AMD resolution with in-memory caching

[robotdan]

Summary

• Refactors Workflow.fetchMetaData() with a two-path AMD resolution strategy:
  1. Savant-native artifacts: Fetch pre-built AMD files from the repo (cached globally in ~/.savant/cache)
  2. Maven artifacts: Generate AMD in-memory from POM using current build's semanticVersions mappings (never persisted to disk)
• Adds in-memory AMD and POM caches (per Workflow instance) to avoid redundant parsing within a single build
• Changes CacheProcess default directory from .savant/cache (per-project) to ~/.savant/cache (global per-user), aligning with the existing integrationDir default
• Eliminates the stale AMD cache problem where changing semanticVersions mappings in the build file required manually deleting .savant/cache

Companion PRs

• Update CacheProcess default dir assertion for new cache strategy savant-core#12

Test plan

• All 76 tests pass (0 failures, 1 pre-existing SVN config skip)
• fetchMetaData_inMemoryCache - verifies same instance returned on second call
• fetchMetaData_mappingsAppliedFresh - verifies stale-cache fix (different mappings produce different results)
• mavenCentral / mavenCentralMapping - verifies AMD files NOT written to disk for Maven artifacts
• GroovyBuildFileParserTest in savant-core (companion PR)

🤖 Generated with Claude Code

[robotdan]

Code Review: Test Coverage Additions

After a thorough code review, the following test gaps were identified and addressed in commit 5d31c34:

Savant-native AMD path (the "other half" of two-path resolution)

• fetchMetaData_savantNativeAmd — pre-built AMD fetched from Savant repo, cached on disk, in-memory cache hit on second call
• fetchMetaData_savantNativeAmd_withDependencies — Savant AMD with compile/runtime dependency groups parsed correctly from pre-built AMD
• fetchMetaData_twoPathResolution_savantThenMaven — single workflow correctly resolves both Savant-native (AMD on disk) and Maven (AMD in-memory) artifacts

Error paths

• fetchMetaData_missingAmdAndPom — ArtifactMetaDataMissingException thrown when neither AMD nor POM exists
• fetchMetaData_missingAmdInSavantRepo_noPomFallback — uses missing-amd test fixture, no Maven fallback available

POM cache verification

• fetchMetaData_pomCacheSharesParents — resolves vertx-core and vertx-web (shared parent chain), verifies both produce correct results proving parent POM cache reuse

Negative source cache

• fetchSource_negativeCacheShortCircuit — verifies .neg marker file is created for missing sources, second call returns null immediately

Workflow configuration variants

• fetchMetaData_cacheOnlyWorkflow — Savant-only workflow (no Maven) resolves via CacheProcess + URLProcess
• fetchMetaData_mavenOnlyWorkflow — Maven-only workflow (no Savant CacheProcess) resolves via POM-to-AMD translation

All 86 tests pass (0 failures).

[robotdan]

Test style cleanup + 2 additional tests (ad9fb50)

Style changes:

• Removed javadoc blocks from new test methods — replaced with inline comments at top of test body to match existing test style
• Removed section separator comments (// ----------) since IntelliJ formatter reorders tests alphabetically and would lose the grouping

New tests added:

• fetchMetaData_amdCacheKeyIncludesName — regression test verifying the AMD cache key includes the artifact name (not just group:project:version). Without the name component, leaf:leaf1 and leaf:leaf2 would return the same cached AMD despite having different licenses/dependencies.
• fetchMetaData_nonSemanticVersionPom — tests the loadPOM() fallback path where a Maven artifact has a non-semantic version (e.g., 1.0.0.Final). Uses the badver test fixture.

All 88 tests pass (0 failures). The 1 config failure is pre-existing (SVNProcessTest — svnadmin not installed).