Maven and Gradle build files

A POM rarely says what it does. The version of a dependency comes from a parent three levels up, or from a BOM imported by a BOM; a property in a child quietly changes a parent’s plugin configuration; a profile switches itself off because another one turned on; and mvn verify runs goals no file mentions. Maven will tell you with mvn help:effective-pom -Dverbose and mvn -X, but you need the project checked out and a network. Here you paste the files and get the same answers, with each value traced to the file and line it came from.

It opens on a multi-module Spring Boot build I wrote for it (an aggregator with ${revision}, two modules, a company BOM, profiles), with trimmed copies of Spring Boot’s parent POMs. The Gradle tab opens on a Spring Boot app written in the Kotlin DSL with a version catalog; there is a Groovy-DSL library too.

How to use it

Maven POM

Paste a pom.xml, or drop files — several at once, or a whole project folder. Add the parents and imported BOMs as more files; each is found by its coordinates (or <relativePath>). The chip on each file says whether it is the project, a parent, a BOM or a module. A parent or BOM that is missing is listed with a link to its POM on Maven Central: download it and drop it in. (The page can’t fetch it for you — Maven Central doesn’t send the CORS headers a browser needs.)
Pick the project to look at, and write the command line as you would type it: mvn -Pci -DskipITs=false clean install. Its -P and -D options feed the model. Set the JDK, OS, environment variables (CI=true) and files that exist to see how profile activation changes. Ticking a profile edits -P for you; each profile says why it is on or off — including the rule that trips everyone up: an <activeByDefault> profile turns off as soon as another profile in the same POM activates.
Effective POM is what mvn help:effective-pom -Dverbose prints: every value with a comment naming the POM, profile and line it came from. Values written as an expression are marked; hover to see which property supplied them. Click a comment to jump to that line in the file.
Dependencies shows each direct dependency’s version and where it came from (declared, managed in which POM, or imported from which BOM), its scope and which classpaths it is on, plus the full <dependencyManagement> table and a reference for scopes and how they combine transitively.
Plugins lists every plugin in the build — yours, inherited, and those the packaging’s lifecycle adds — with the version source, each execution’s phase (and where that phase came from), and the merged configuration with provenance.
Build plan lists every phase of every lifecycle the command touches and the mojo executions bound to each, in the order Maven runs them; skipped goals (-DskipTests, <skipITs>) and goals that fork their own lifecycle are marked. Goals called directly (dependency:tree, spring-boot:run) are shown with the plugin version they would use.
Properties shows every property, its value and every POM that defines it, nearest first.
Problems has Maven’s own warnings in its own words (duplicate dependencies, missing versions, plugins without a version) and more: a SNAPSHOT in a release, version ranges and LATEST, the system scope, a child property that downgrades a version a parent manages, -D overrides, release vs source/target, plain-http repositories, and <dependencyManagement> entries no module of the build uses.

Gradle

Paste build.gradle or build.gradle.kts, and add settings.gradle(.kts), gradle/libs.versions.toml and gradle.properties if you have them.
Dependencies lists each declaration with its configuration, its version (and whether it comes from the catalog, a platform, a BOM or a constraint) and the classpaths it lands on. If a BOM the build imports is pasted in the Maven tab, the versions it manages are filled in.
Configurations draws the graph the applied plugins create (java, java-library, war, Kotlin, Spring Boot): where you declare dependencies, what Gradle resolves, and what other projects consume. Click one to follow it.
Version catalog shows each alias, the accessor Gradle generates for it (spring-boot-starter-web becomes libs.spring.boot.starter.web), its version, and whether the build uses it.
Problems covers removed configurations (compile), dependencies nothing gives a version, JUnit 5 without junit-platform-launcher (Gradle 9 fails), Lombok outside annotationProcessor, dynamic versions, enforcedPlatform in a library, jcenter() and more — and lists, with line numbers, the statements it didn’t analyse. A build script is a program; this reads the common subset of the DSL, it doesn’t run it.

Convert

POM → Gradle takes the build in the Maven tab and writes settings, one build script per module and gradle/libs.versions.toml in the Kotlin or Groovy DSL. Spring Boot parents become the Boot plugin; BOMs become either Spring’s dependency-management plugin or platform(); scopes, optional dependencies, exclusions, annotation processors, the Java release, compiler arguments and the main class carry over. It lists what didn’t (profiles, plugins with no direct equivalent) and — this matters — the versions that will come out differently because Gradle combines BOMs differently from Maven.
Gradle → POM is best effort: dependencies and scopes, platforms and BOMs, constraints, strict versions, annotation processors, the toolchain and the Spring Boot parent.
Groovy ↔ Kotlin rewrites plugins {}, dependencies {} and the simple statements around them (ext, java {}, task blocks), keeping comments.

Versions & conflicts

Compare two versions by Maven’s ComparableVersion and by Gradle’s ordering side by side, sort a list, and test a Maven range like [1.0,2.0). The conflict lab takes a tiny dependency graph and shows what Maven (nearest wins) and Gradle (highest wins) pick, as mvn dependency:tree -Dverbose and gradle dependencies would print it.

For real dependency trees — mvn dependency:tree or gradle dependencies output, lockfiles — use the dependency tree analyser. For npm, Cargo and Python version ranges, the version ranges tool. For application.properties and Actuator output, the Spring Boot tool; for what’s inside a jar, the class file inspector.

How it was checked

I wanted these answers to be the ones Maven and Gradle give, so I compared them with the real tools (Maven 3.9.9, Gradle 8.14.1):

The effective POM of every built-in sample matches mvn help:effective-pom -Dverbose value for value, including every "POM, line N" comment, with and without profiles, -D options and environment variables. Against the real Spring Boot 3.4.5 parents and all 42 BOMs they import, it matched all ~5,000 values per module.
The build plan matches the executions mvn -X lists for several command lines.
Version ordering matches Maven’s ComparableVersion and VersionRange (5,298 checks) and Gradle’s own comparator (4,489 checks), quirks included.
The conflict lab matches mvn dependency:tree and gradle dependencies on eight graphs.
The configuration graph is the one Gradle prints for each plugin.
Converted builds build: the Spring Boot sample as Gradle (Kotlin and Groovy, both BOM styles), the Gradle samples as POMs, and the Groovy ↔ Kotlin conversions, which give identical gradle dependencies output.

What it doesn’t do: resolve transitive dependencies (that needs a repository), run Gradle build logic, or know what a Maven build extension changes at build time. Plugins that inject executions (nexus-staging), packagings from extensions other than bundle, the os-maven-plugin properties' timing, and the old <reporting> section’s conversion into the site plugin may differ from Maven.

It works in any current browser. A share link carries the chosen samples, tabs and command line — not the files you pasted.

Privacy

Everything is read and computed in this page; nothing you paste or drop is uploaded, and the page makes no network requests of its own. The links to Maven Central for missing POMs only open when you click them. Your files are kept in this browser’s local storage so they are still here next time; Clear removes them.

The trimmed spring-boot-starter-parent, spring-boot-dependencies (Spring, Apache License 2.0) and jackson-bom (FasterXML, Apache License 2.0) in the samples say at the top what was removed. The super POM and lifecycle bindings are Maven 3.9.9’s (Apache License 2.0).