BuildFileParseStage

Stage 3 of the LST classpath-resolution pipeline: parse build descriptors statically (no subprocess) and resolve declared dependencies via full POM traversal using Maven Resolver (Eclipse Aether).

Why Stage 3? Stage 2 (DependencyResolutionStage) requires the build tool to be available as a subprocess. Stage 3 is the fallback when Stage 2 fails — for example, when Maven/Gradle is not installed, when subprocess invocations time out, or when the project has an incomplete build setup.

How it works:

1. Build files (pom.xml, build.gradle, build.gradle.kts) are parsed statically via io.github.skhokhlov.rewriterunner.lst.utils.StaticBuildFileParser to extract groupId:artifactId:version coordinates.

2. All coordinates are passed to resolveWithPomTraversal for full POM traversal, applying Maven conflict resolution (nearest-wins) across the full transitive graph.

Maven projects: Discovers all pom.xml files (root, declared <modules>, and subdirectories up to depth 3 for projects without a root aggregator POM) and collects their declared dependencies.

Gradle projects: Delegates to io.github.skhokhlov.rewriterunner.lst.utils.StaticBuildFileParser.parseGradleDependenciesStatically, which handles multi-module projects via settings.gradle discovery and version catalogs under gradle/\*.versions.toml.

Mixed Maven+Gradle projects: Both paths are attempted and coordinates combined.

Failure behaviour: When no coordinates are found, returns an empty list, causing LstBuilder to fall through to LocalRepositoryStage (Stage 4).

Extensibility: The class is open with open methods so tests can subclass it to intercept resolution calls without triggering network access.