Bazel has deprecated the WORKSPACE file for dependency management and
will
remove support entirely in Bazel 9 (currently in RC as of Nov 2025). The
WORKSPACE system required all transitive dependencies to be manually
declared and had no version resolution mechanism, leading to diamond
dependency conflicts. Bzlmod replaces this with a proper module system
that uses Minimal Version Selection (MVS) for automatic dependency
resolution.

This commit migrates Batfish from WORKSPACE to bzlmod by creating a
MODULE.bazel file that declares all external dependencies as Bazel
modules from the Bazel Central Registry (BCR) where available.

## Key Architectural Changes

### Dependency Declaration (WORKSPACE → MODULE.bazel)
- WORKSPACE: Dependencies declared via http_archive with manual URL/SHA,
required calling *_deps() macros to load transitive dependencies, no
version resolution for diamond dependencies
- bzlmod: Dependencies declared via bazel_dep() with semantic versions,
automatic transitive dependency resolution via MVS, all modules from
BCR include their own MODULE.bazel declaring their dependencies

### Maven Dependencies (maven_install → maven extension)
- WORKSPACE: Called maven_install() directly in WORKSPACE, loaded
artifact list from library_deps.bzl using load(), used
maven.artifact() with inline maven.exclusion() for exclusions
- bzlmod: Use maven extension with maven.install() tags, artifact lists
defined as constants in MODULE.bazel (MODULE.bazel cannot use load()
statements), exclusions applied separately via maven.amend_artifact()
to keep artifact lists compact
- Artifact classifiers (e.g., antlr4:complete, jol-cli:full) specified
with colon syntax: "group:artifact:version:classifier"

### Python Dependencies (pip_parse → pip extension)
- WORKSPACE: Called pip_parse() with explicit interpreter from
python_register_toolchains(), required load() from registered Python
toolchain to get interpreter
- bzlmod: Use python extension for toolchain registration, then pip
extension for package installation with requirements.txt, cleaner
separation of toolchain vs packages

### Tool Dependencies (http_archive/http_jar → BCR or Maven)
- WORKSPACE: Used http_archive for buildifier (6.4.0) and http_jar for
ANTLR4 complete jar - both fetched as single files without transitive
dependencies
- bzlmod: Buildifier available in BCR as bazel_dep(), ANTLR4 complete
jar available via Maven using classifier syntax with exclusions to
eliminate unwanted transitive dependencies (the complete jar is
standalone and doesn't need antlr-runtime, ST4, etc.)

## Specific Changes

### New Files
- MODULE.bazel (189 lines): Module definition with all dependency
declarations
- Maven artifact lists defined as constants (BATFISH_MAVEN_ARTIFACTS,
BATFISH_MAVEN_BOMS, JOL_MAVEN_ARTIFACTS, JMH_MAVEN_ARTIFACTS) at top
of file since MODULE.bazel cannot use load() statements
- Module metadata (name "batfish", version "0.0.0")
- Direct dependencies via bazel_dep() for core Bazel modules, Java
rules, Python rules, and dev tools
- Maven artifacts via maven extension with 3 separate maven.install()
tags: main (all Batfish deps), jol_maven (GPL tool), jmh_maven (GPL
tool)
- maven.amend_artifact() calls to add exclusions: junit exclusions for
3 test artifacts, transitive dependency exclusions for antlr4
complete jar
- Python toolchain and pip packages via extensions
- No custom extensions needed
- MODULE.bazel.lock (619 lines): Auto-generated lockfile capturing
resolved dependency graph for reproducible builds across machines

### Modified Files
- WORKSPACE: Reduced from 186 lines to 4 lines
- Removed all http_archive, maven_install, pip_parse, toolchain
registration
- Kept minimal workspace(name = "batfish") declaration per migration
guide recommendation
- Added comment pointing to MODULE.bazel
- .bazelrc: Removed WORKSPACE/bzlmod toggle flags
- Removed --enable_bzlmod=False (was explicitly disabling bzlmod)
- Removed --enable_workspace (was required for WORKSPACE in Bazel 8)
- bzlmod now enabled by default in Bazel 8+
- maven_install.json: Regenerated for bzlmod format
- Input signature changed to reflect MODULE.bazel source
- Now includes transitive Maven dependencies from protobuf module
(gson, error_prone_annotations, guava at older versions cause
duplicate warnings)
- Includes antlr4-complete classifier artifact without transitive deps
- skylark/antlr.bzl: Changed antlr_tool default label
- Old: "@antlr4_tool//jar" (custom http_jar repository)
- New: "@maven//:org_antlr_antlr4_complete" (Maven artifact)
- docs/building_and_running/README.md: Updated dependency upgrade
instructions
- Changed references from library_deps.bzl to MODULE.bazel
- Updated pin command from "@unpinned_maven//:pin" to "REPIN=1 bazel
run @maven//:pin"
- Fixed markdown rendering (rules_jvm_external instead of
rules_jvm_external)
- Added link to rules_jvm_external bzlmod documentation
- Multiple BUILD.bazel files (16 files): Added explicit load()
statements
- load("@rules_java//java:java_library.bzl", "java_library")
- load("@rules_java//java:java_binary.bzl", "java_binary")
- load("@rules_shell//shell:sh_test.bzl", "sh_test")
- load("@rules_shell//shell:sh_binary.bzl", "sh_binary")
- Required because bzlmod deprecates native.java_library() etc in favor
of explicit loads

### Dependency Upgrades
- buildifier_prebuilt: 6.4.0 → 8.2.1
- Now pulled from BCR as bazel_dep() instead of http_archive
- Marked as dev_dependency = True (not needed by consumers)
- Toolchain auto-registered by the module
- rules_python: 0.40.0 → 1.4.1
- Required by [email protected] transitive dependency
- MVS selected 1.4.1 as minimum version satisfying all dependents
- rules_shell: 0.4.0 (new dependency)
- Added to support sh_test and sh_binary rules used by ref_tests.bzl
and tools
- Required for explicit load() statements in BUILD files

### Maven Artifacts
- Added: "org.antlr:antlr4:4.13.2:complete" (moved from http_jar)
- Excluded all transitive deps via maven.amend_artifact() since
complete jar is standalone (was bringing in antlr-runtime, ST4,
treelayout, icu4j, javax.json)
- All other artifacts remain at same versions as library_deps.bzl
- Four artifacts have exclusions applied via maven.amend_artifact():
- org.antlr:antlr4 (excludes all transitive deps)
- com.google.guava:guava-testlib (excludes junit:junit)
- org.glassfish.jersey.test-framework:jersey-test-framework-core
(excludes junit:junit)
-
org.glassfish.jersey.test-framework.providers:jersey-test-framework-provider-grizzly2
(excludes junit:junit)

## Migration Approach

Followed the recommended bzlmod migration process from
https://bazel.build/external/migration:

1. Created MODULE.bazel with bazel_dep() for all BCR-available
dependencies (bazel_skylib, rules_license, bazel_features, rules_java,
rules_jvm_external, rules_python, buildifier_prebuilt, rules_shell)

2. Configured Maven dependencies via maven extension:
- Defined artifact lists as constants at top of MODULE.bazel
(BATFISH_MAVEN_ARTIFACTS, BATFISH_MAVEN_BOMS, JOL_MAVEN_ARTIFACTS,
JMH_MAVEN_ARTIFACTS) since MODULE.bazel cannot use load() statements
- Created maven.install() tag for main Batfish dependencies
- Created separate maven.install() tags for jol_maven and jmh_maven
(GPL-licensed tools isolated in separate Maven namespaces)
- Used maven.amend_artifact() to add exclusions without fragmenting
artifact lists
- Added ANTLR4 complete jar as Maven artifact with classifier syntax
- Excluded all transitive deps from antlr4:complete since the complete
jar is standalone

3. Configured Python via python and pip extensions:
- Used python extension to register Python 3.10 toolchain
- Used pip extension to install packages from requirements.txt

4. Eliminated all custom repository rules:
- ANTLR4 complete jar: http_jar → Maven artifact with :complete
classifier plus exclusions to prevent transitive dependency
resolution
- Buildifier: http_archive → bazel_dep from BCR
- No custom module extensions required

5. Regenerated all Maven lock files via REPIN=1:
- maven_install.json (main dependencies)
- tools/jol/jol_maven_install.json (JOL tool)
- tools/benchmarks/jmh_maven_install.json (JMH tool)

6. Updated build files:
- Minimized WORKSPACE to 4 lines per migration guide
- Removed bzlmod toggle flags from .bazelrc
- Added explicit load() statements to BUILD.bazel files
- Updated skylark/antlr.bzl to reference Maven artifact

7. Updated documentation:
- docs/building_and_running/README.md now references MODULE.bazel for
dependency upgrades

8. Verified complete migration:
- bazel build //... - 921 targets, all successful
- bazel test //... - 358 tests, all passing
- bazel run //:buildifier.check - formatting verified

## Benefits Achieved

- Automatic transitive dependency resolution: No more manual *_deps()
macro calls, protobuf's dependencies automatically resolved
- Proper version resolution: MVS handles diamond dependencies (e.g.,
protobuf wants guava 32.0.1-jre, we want 33.4.0-jre, MVS selects
33.4.0-jre)
- Central registry: All major dependencies pulled from BCR with version
guarantees
- Lockfile support: MODULE.bazel.lock and maven_install.json ensure
reproducible builds
- Strict visibility: Only direct dependencies visible, prevents
accidental transitive dependency usage
- Simpler structure: No more layered *_deps() macros, all dependencies
in one place
- Better tooling: bazel mod graph shows full dependency tree
- Cleaner Maven dependencies: Artifacts organized in named arrays,
exclusions applied separately via maven.amend_artifact()

## Bzlmod Limitations and Workarounds

### MODULE.bazel cannot use load() statements
Artifact lists must be defined as constants in MODULE.bazel rather than
in separate .bzl files. This is a fundamental bzlmod restriction - the
MODULE.bazel file is parsed before any .bzl files are available. We
define BATFISH_MAVEN_ARTIFACTS, JOL_MAVEN_ARTIFACTS, and
JMH_MAVEN_ARTIFACTS as constants at the top of MODULE.bazel.

### Exclusions cannot be inlined
In WORKSPACE, we used maven.artifact(exclusions=[maven.exclusion(...)])
inline. In bzlmod, maven.artifact() returns None rather than a dict, so
it cannot be inlined in the artifacts list. We use
maven.amend_artifact()
to add exclusions after declaring artifacts.

### Module dependency layering
The protobuf module also contributes to the "maven" repository, adding
older versions of gson, error_prone_annotations, and guava. MVS
correctly
selects our newer versions. We add known_contributing_modules to
suppress
the warning about this expected behavior.

## Known Warnings

- Duplicate artifact versions from protobuf module: [email protected]
contributes older versions of gson (2.8.9 vs 2.13.2),
error_prone_annotations (2.5.1 vs 2.43.0), and guava (32.0.1-jre vs
33.4.0-jre). MVS correctly selects our newer versions.
- Added known_contributing_modules = ["batfish", "protobuf"] to
maven.install() to suppress layering warning per documentation.

Reference: https://bazel.build/external/migration

---
Prompt:
```
Bazel is about to end the WORKSPACE support we currently use. Read about the migration to bzlmod, analyze our current build structure, and execute. https://bazel.build/external/migration Feel free to fetch other documentation, including using curl instead of the MCP if needed. Youc an also use the `gh` github tool to fetch packages or inspect issues, docs, etc.
```