Maven compatibility

Barista is defined against Maven. It reads the same project and configuration files, writes into the same local repository, and is benchmarked for parity against mvn on every release. The goal is that an existing project works the day you switch — no pom.xml edits, no migration, no lock-in.

What Barista reads

• pom.xml — full parsing with parent merge, property interpolation, BOM imports, profile activation, and dependencyManagement.
• ~/.m2/settings.xml — mirrors, servers, and proxies are honored, the same as Maven.
• ~/.m2/repository — the shared local repository. Barista populates it; Maven and mvnd read from it.

Bundled Maven, and the versions we target

Barista bundles a pinned Apache Maven 4.0.0-rc-3 distribution, so resolution and caching work without a separate mvn install. Plain mvn remains the ground-truth reference: every release is benchmarked against mvn 3.9.x, mvn 4.0.x, and mvnd 2.x. Choose the behavior explicitly when you need to:

barista pull --maven-compat auto   # detect from the project (default)
barista pull --maven-compat 3.9    # Maven 3.9-compatible behavior
barista pull --maven-compat 4.0    # Maven 4.0-compatible behavior

Coexisting with mvn and mvnd

• Bidirectional artifact sharing. Artifacts fetched by mvn / mvndare ingested into Barista’s content-addressed cache (checksum-verified) when next touched; artifacts Barista resolves are hardlinked back into ~/.m2/repository so the other tools see them.
• Independent daemons. Barista’s barback and Maven’s mvnd are separate processes with no shared state — you can run both.
• barista.lock is Barista-specific. mvn and mvnd ignore it, so it is safe to commit alongside a Maven project.

Dependency scopes

Resolution is scope-aware, matching Maven’s scopes: compile, runtime, test, provided, and system. Narrow a resolve with --scope.

Not supported in v0.1

Barista is Maven-specific — there is no Gradle support. Within the Maven surface, this pre-release is honest about what is not wired yet:

• Windows lifecycle execution. The lifecycle commands build via the barbackdaemon on macOS and Linux, but the daemon isn’t wired on Windows yet — pass --no-daemon there to fork to your installed mvn.
• Multi-module reactor. Single-module builds are proven; reactor (multi-module) support is still maturing.
• Tap routing. Remote caches / workers can be registered with barista tap, but build actions are not routed to them yet.

See the CLI reference for the exact command-by-command status.