How to convert json to a maven pom.xml file
- Step 1Mirror the POM structure in JSON — Model the JSON to match the XML you want. Top-level keys like
modelVersion,groupId,artifactId,version,packaging, plus adependenciesobject containing adependencyarray. Set the Root element option toproject. - Step 2Add the Maven schema namespaces — The converter won't add them. Put them on the project object as attributes:
"@xmlns": "http://maven.apache.org/POM/4.0.0","@xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance","@xsi:schemaLocation": "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd". - Step 3Model dependencies as a repeated key — Use
{ "dependencies": { "dependency": [ { "groupId": "...", "artifactId": "...", "version": "..." } ] } }. Each array element becomes a<dependency>. Addscopeexplicitly where needed — there is no auto-default tocompile. - Step 4Add properties and plugins — A
propertiesobject maps each key to a<properties>child. For plugins, nest{ "build": { "plugins": { "plugin": [ ... ] } } }; a plugin'sconfigurationobject maps recursively to nested<configuration>elements. - Step 5Pick indent and convert — Choose 2 or 4 spaces to match your editor's POM formatting. Keep XML declaration on. Click Convert to XML, Download, and rename to
pom.xml. - Step 6Validate the build — Run
mvn validate(or open in your IDE). Maven reports unresolved coordinates, missingmodelVersion, or schema issues the converter doesn't check. Fix coordinates in the JSON and re-convert, or merge the<dependencies>block into an existing POM.
JSON shape → pom.xml elements
Structural mapping with Root element = project. The converter mirrors structure exactly and copies values verbatim — no Maven defaults are applied.
| JSON | XML | Tool behaviour |
|---|---|---|
{ "@xmlns": "http://...POM/4.0.0" } | <project xmlns="http://...POM/4.0.0"> | @-prefixed key → attribute on <project> |
"dependencies": { "dependency": [ {...}, {...} ] } | <dependencies><dependency>...</dependency>...</dependencies> | dependency array repeats under its own key |
{ "groupId": "org.x", "artifactId": "y", "version": "1.0" } | Three child elements inside <dependency> | Order preserved from JSON key order |
"properties": { "spring.version": "6.1" } | <properties><spring.version>6.1</spring.version></properties> | Key with a dot is a valid element name; passed verbatim |
| scope omitted | no <scope> element | NOT defaulted to compile (Maven applies that at build time) |
"configuration": { "source": "17" } | <configuration><source>17</source></configuration> | Nested objects map recursively |
Maven specifics the converter does NOT handle
Things a real Maven generator would do that this structural tool leaves to you or to Maven itself. Older claims of automatic schema/defaults are inaccurate.
| Maven concern | Converter? | Where it's handled |
|---|---|---|
| Inject POM 4.0.0 namespace block | No | Add @xmlns / @xmlns:xsi / @xsi:schemaLocation keys |
| Default missing scope to compile | No | Maven applies the default at build time; add scope explicitly if you want it written |
| Validate groupId/artifactId resolve | No | mvn validate / your repository check |
| Require modelVersion 4.0.0 | No | Include "modelVersion": "4.0.0" in the JSON |
Escape &, <, > in values | Yes | Automatic entity escaping |
Cookbook
Real JSON configs and the exact pom.xml XML the converter produces. Set root = project, add the schema attributes, and model repeated elements (dependency, plugin, module) as arrays under their singular key.
Minimal buildable POM
ExampleInclude modelVersion and coordinates, plus the schema namespace attributes on the project object. This is the smallest config Maven will validate.
Input JSON:
{
"@xmlns": "http://maven.apache.org/POM/4.0.0",
"@xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance",
"@xsi:schemaLocation": "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd",
"modelVersion": "4.0.0",
"groupId": "com.example",
"artifactId": "app",
"version": "1.0.0"
}
Options: Root element = project, indent = 2
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>app</artifactId>
<version>1.0.0</version>
</project>Dependencies block from a scanner's JSON
ExampleNest a dependency array under dependencies. Each entry becomes a <dependency>. Add scope only where you need it — it is not auto-filled.
Input JSON:
{ "dependencies": { "dependency": [
{ "groupId": "org.springframework", "artifactId": "spring-core", "version": "6.1.0" },
{ "groupId": "junit", "artifactId": "junit", "version": "4.13.2", "scope": "test" }
] } }
Options: Root element = project
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>6.1.0</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>Properties for version constants
ExampleA flat properties object becomes one child per key. Dotted keys like spring.version are valid XML element names and pass through unchanged.
Input JSON:
{ "properties": { "java.version": "17", "spring.version": "6.1.0" } }
Options: Root element = project
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<properties>
<java.version>17</java.version>
<spring.version>6.1.0</spring.version>
</properties>
</project>Plugin with nested configuration
ExamplePlugins nest under build.plugins.plugin. A configuration object maps recursively, so source/target become child elements inside <configuration>.
Input JSON:
{ "build": { "plugins": { "plugin": [
{ "groupId": "org.apache.maven.plugins",
"artifactId": "maven-compiler-plugin",
"version": "3.13.0",
"configuration": { "source": "17", "target": "17" } }
] } } }
Output XML (fragment):
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
<configuration>
<source>17</source>
<target>17</target>
</configuration>
</plugin>
</plugins>
</build>Multi-module parent POM
ExampleModel the reactor modules as a module array under modules. Each entry becomes a <module> directory reference.
Input JSON:
{ "packaging": "pom",
"modules": { "module": [ "core", "web", "cli" ] } }
Options: Root element = project
Output XML:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<packaging>pom</packaging>
<modules>
<module>core</module>
<module>web</module>
<module>cli</module>
</modules>
</project>Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
You expected the POM schema namespace to be added
By designThe converter does NOT inject the xmlns="http://maven.apache.org/POM/4.0.0" block or xsi:schemaLocation. Add them yourself as @-prefixed keys on the project object (see the minimal-POM cookbook entry). Maven tolerates a POM without the namespace, but IDEs and schema validation work better with it present.
scope omitted, expecting compile
Not defaultedMaven defaults a missing <scope> to compile at build time, but the converter does not write a <scope>compile</scope> element for you — it only emits what's in the JSON. The build still behaves correctly (Maven applies the default), so this is cosmetic unless a tool reads the raw POM expecting an explicit scope.
dependency array flattened into one <dependency>
Wrong shapeIf you write { "dependencies": [ {...}, {...} ] } (array directly under dependencies, no inner dependency key), you get <dependencies> containing flattened children, not repeated <dependency> blocks. Maven needs each dependency wrapped, so use the dependencies.dependency array form shown in the cookbook.
Coordinates don't resolve
mvn build failureThe converter does not validate groupId/artifactId/version against Maven Central or your Nexus. A typo'd coordinate produces valid XML that fails at mvn compile with 'Could not resolve dependencies'. Validate coordinates before converting; the tool is purely structural.
Missing modelVersion
mvn validate failureMaven requires <modelVersion>4.0.0</modelVersion>. The converter writes it only if your JSON includes "modelVersion": "4.0.0". Omit it and mvn validate fails with 'modelVersion' is required. Always include it as a top-level key.
Invalid JSON pasted
Parse errorInput runs through JSON.parse; a trailing comma or unquoted key throws and nothing converts. SBOM and scanner outputs are usually clean JSON, but hand-edited configs aren't — repair with json-format-fixer.
An & in a repository URL or comment
Escaped (correct)A literal & in a value (e.g. a repository URL with query parameters) is escaped to &, keeping the POM well-formed. Don't pre-escape in your JSON or you'll get &amp;. Angle brackets and quotes are escaped too.
Large generated POM over the free limit
Blocked (Pro)JSON to XML is Pro. Free inputs are capped at 2 MB; Pro at 100 MB. A normal POM is tiny, but a generated dependency-tree dump from a large monorepo audit could exceed 2 MB of JSON and need Pro. Conversion runs in-browser regardless.
Frequently asked questions
How do I get repeated <dependency> elements?
Nest a dependency array under dependencies: { "dependencies": { "dependency": [ {...}, {...} ] } }. An array inside an object repeats under its own key, so each entry becomes a <dependency> inside <dependencies>. Set the Root element option to project.
Does the tool add the Maven POM namespace and schemaLocation?
No. Add them as attributes on the project object: @xmlns, @xmlns:xsi, and @xsi:schemaLocation (the @ prefix turns each into an attribute). See the minimal-POM example. Maven runs without them, but IDE schema awareness and validation work better when they're present.
Will a missing scope default to compile?
Not in the output. The converter only emits elements present in the JSON, so an omitted scope produces no <scope> element. Maven itself applies the compile default at build time, so the build is correct — but if you want the scope written explicitly, add "scope": "compile" to the dependency object.
Are dotted property keys like spring.version valid?
Yes. A dot is legal in an XML element name, so "spring.version": "6.1.0" becomes <spring.version>6.1.0</spring.version>. That's exactly the convention Maven <properties> use. Keys with spaces or leading digits, however, produce malformed element names — avoid those.
Can I generate a multi-module parent POM?
Yes. Set "packaging": "pom" and model the reactor as { "modules": { "module": [ "core", "web" ] } }. Each array element becomes a <module>. Convert each child module's own dependency config separately to produce its module-level pom.xml.
How do I add plugin execution configuration?
Nest it structurally: build.plugins.plugin is an array; each plugin object can carry executions.execution (another array) and a configuration object. Because nested objects map recursively, the configuration tree mirrors your JSON exactly. There's no plugin helper — you model the XML shape in JSON.
Does the tool validate that my coordinates resolve?
No. It's a structural converter, not a dependency resolver. A typo'd groupId or a non-existent version produces valid XML that fails at mvn compile. Validate coordinates against Maven Central or your internal repository before converting.
Why did my dependencies come out without <dependency> wrappers?
You probably put the array directly under dependencies ("dependencies": [ ... ]) instead of under an inner dependency key. Maven needs each dependency wrapped in <dependency>, so use { "dependencies": { "dependency": [ ... ] } }. The inner key name drives the repeating element.
Can I merge just the dependencies into an existing POM?
Yes. Convert only the { "dependencies": { "dependency": [...] } } fragment (set the root to dependencies or copy just that block from the output), then paste it into your existing pom.xml with your IDE's XML merge. The converter doesn't merge files — it produces one document per run.
Are my internal artifact coordinates uploaded anywhere?
No. Conversion is fully client-side. Internal artifact versions, private Nexus/Artifactory coordinates, and project metadata never reach JAD Apps servers. Only an anonymous run counter (no content) is recorded for signed-in dashboard stats.
How large a config can I convert?
JSON to XML is Pro. Free tier caps the input at 2 MB; Pro at 100 MB. A normal POM config is well under 1 MB, so free tier is usually plenty; a large monorepo dependency-tree dump might need Pro. Processing is in-browser.
How do I turn an existing pom.xml back into JSON?
Use xml-to-json, with removeNSPrefix if you want to drop any namespace prefixes. To pull a specific value out of the parsed POM — say every dependency's version — json-path-extractor can run $.project.dependencies.dependency[*].version.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.