Import Maven build

bleep import-maven reads your pom.xml (and any sibling modules in a multi-module reactor) and produces a working bleep.yaml. It runs mvn help:effective-pom under the hood, which resolves all <dependencyManagement> versions, parent-POM inheritance, and active profiles.

Run the import

From the directory containing your top-level pom.xml:

bleep import-maven

Bleep:

1. Shells out to mvn -DskipTests -DskipITs -Doutput=... help:effective-pom to materialize the resolved POMs, caching the output in .bleep/import/maven/.
2. Parses each module, skipping packaging: pom parent modules.
3. Detects test frameworks from your dependencies (junit5, junit4, scalatest, specs2, munit, utest, zio-test, weaver-cats) and wires the appropriate sbt test-interface adapter.
4. Detects the Java release from maven-compiler-plugin's <release> and pins the JVM via jvm.name: temurin:NN.
5. Carries over any non-default <repositories> as bleep resolvers:.
6. Writes bleep.yaml to your build root.

Useful flags

• --skip-mvn — re-use a previously-cached effective-pom.xml from .bleep/import/maven/ instead of re-invoking mvn. Useful when iterating on import flags.
• --mvn-path /usr/local/bin/mvn — point at a non-default mvn binary.
• --exclude-project NAME — skip a specific module and everything downstream of it. Repeat for multiple.
• --ignore-when-templating NAME — keep the project but don't let it influence template inference. Useful for outlier modules (documentation, examples) whose unique config would otherwise create a one-off template.
• --platform jvm|js|native — restrict the import to projects on the given platform.
• --scala 213|3 — restrict to projects on the given Scala version.

What gets preserved

from pom.xml	to bleep.yaml
Multi-module reactor (<modules>)	sibling projects in projects:
<dependencies>	dependencies:
Inter-module dependencies (group:artifact match within reactor)	dependsOn:
Test-framework dependencies (junit5/scalatest/munit/...)	testFrameworks: + auto-injected sbt-test-interface adapter
<repositories> (non-Maven Central)	resolvers:
maven-compiler-plugin <release>	jvm.name: temurin:NN
<dependencyManagement> resolved versions	inlined into dependencies: (since bleep has no BOM model yet)

What gets stripped

• Parent POMs / packaging: pom modules — these have no source, so they don't survive as bleep projects. Their effects on child modules are already merged in via mvn help:effective-pom.
• Build plugins beyond compile/test/jar — bleep doesn't run Maven plugins. Things like maven-shade-plugin, frontend-maven-plugin, maven-failsafe-plugin, etc. become your problem to re-implement as scripts. See Porting sbt plugins for the general pattern; the same logic applies to Maven plugins.
• Active-by-default profiles — mvn help:effective-pom activates default profiles, but bleep doesn't preserve profile structure. You'll get the union of what was active at import time.
• <scope>provided</scope> — bleep models provided (configuration field) but the import is conservative; review imported dependencies for scopes that need adjustment.

After importing

bleep compile
bleep test

Both should work without further changes for the common case. If you hit gaps:

• Annotation processors — Lombok, MapStruct, Dagger. Add java.annotationProcessing.enabled: true per project. See Annotation Processing.
• Custom packaging — fat JAR, shade, executable JAR. Convert the Maven plugin invocation into a bleep script.
• Generated sources (e.g. JAXB, OpenAPI codegen via plugin) — same story; convert to a sourcegen script.
• Publishing — Maven's mvn deploy setup doesn't carry over directly. See Publish to Maven Central for bleep's bleep publish sonatype flow, or use bleep publish <named-resolver> for an internal Nexus/Artifactory.

Limits today

• Gradle import is not yet implemented. Multi-tool repos that mix Maven and Gradle modules can import the Maven half today; the Gradle half is manual.
• BOMs are inlined at import time; bleep has no dependencyManagement equivalent yet, so dependencies imported through spring-boot-dependencies or similar will end up with explicit versions in bleep.yaml.
• Profiles — only the mvn help:effective-pom default activation is captured.