# polyglot-maven, writing your POM in Ruby, YAML or Kotlin

> Takari's polyglot-maven lets a Maven build read a POM written in a different markup language, including Ruby, YAML, Kotlin, Groovy, Scala, Clojure, Atom and plain Java. It installs as a core extension, and it comes with real limits around release tooling and mixed-dialect reactors.

**takari/polyglot-maven** — Support alternative markup for Apache Maven POM files

- Repository: https://github.com/takari/polyglot-maven
- Stars: 919 · Forks: 105
- Language: Java
- License: EPL-1.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/takari-polyglot-maven

## The POM model in a language other than XML

Polyglot for Maven is a set of extensions for Maven 3.3.1 and later that allow the POM model to be written in dialects other than XML. The repository description puts it plainly: support alternative markup for Apache Maven POM files.

The dialects available, with their artifact ids, are Atom, Groovy, Clojure, Kotlin, Ruby, Scala, YAML, Java and XML, all published under the groupId io.takari.polyglot. The README's example is a POM written in the Ruby dialect, and it is a complete and readable build definition rather than a toy:

```ruby
project 'Polyglot :: Aggregator' do

  model_version '4.0.0'
  id 'io.tesla.polyglot:tesla-polyglot:0.0.1-SNAPSHOT'
  inherit 'io.tesla:tesla:4'
  packaging 'pom'

  properties( 'sisuInjectVersion' => '0.0.0.M2a',
              'teslaVersion' => '3.1.0' )

  overrides do
    jar 'org.eclipse.sisu:org.eclipse.sisu.inject:${sisuInjectVersion}'
    jar 'org.apache.maven:maven-model-builder:3.1.0'
    jar( 'junit:junit:4.11', :scope => 'test' )

  end

  plugin 'org.codehaus.plexus:plexus-component-metadata:1.5.4' do
    execute_goals 'generate-metadata', 'generate-test-metadata'
  end
end
```

The value of the dialect is not novelty, it is that the file becomes something with the syntax of the language your team already uses. Properties, dependencies and plugins are written in expressions the team reads elsewhere, and the Ruby dialect even supports blocks and the interpolation of a property inside a coordinate.

Several of the dialects also allow inlined plugins. The README names Ruby, Groovy and Scala as the ones that do, which is the detail to check first, because a plugin with a configuration block inside the POM is what most people are trying to achieve.

## Installing it as a Maven core extension

Polyglot is used as a Maven core extension, so enabling it means editing a file in the .mvn directory of the project rather than adding a plugin to the build.

The README says you need to edit ${maven.multiModuleProjectDirectory}/.mvn/extensions.xml and add the appropriate language extension. The file to create is short:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<extensions>
  <extension>
    <groupId>io.takari.polyglot</groupId>
    <artifactId>ARTIFACTID</artifactId>
    <version>0.4.6</version>
  </extension>
</extensions>
```

You replace ARTIFACTID with the artifact id for the dialect you want, so polyglot-ruby or polyglot-yaml, and the extension is resolved like any other Maven artifact at the start of the build.

Two practical notes. The version in the example is 0.4.6, while the most recent release listed for the project is polyglot-0.8.2, dated 2026-07-01, so the snippet in the README is behind and you should pin the version you actually want. And the file lives at the root of the multi-module directory, which means one extension applies to the whole reactor.

There is a separate configuration parameter for the Scala dialect, polyglot.scala.outputdir, which specifies a different output directory. The reason given is that it avoids the deletion that happens during a Maven clean phase, if you set it to a different folder such as .polyglot-cache instead of the default target. An example setup lives in polyglot-maven-examples/scala/.mvn/maven.config.

For runtime use the requirements are Maven 3.6.3 or later and Java 8 or later. Building the project itself needs Maven 3.9 and Java 17.

## Converting an existing pom.xml back and forth

The project ships a Maven plugin for converting existing POM files, which is what makes adoption less scary. The invocation is:

```bash
mvn io.takari.polyglot:polyglot-translate-plugin:translate \
  -Dinput=pom.xml -Doutput=pom.{format}
```

The supported output formats are rb, groovy, scala, yaml, atom, java and of course xml. You can convert back to xml, and you can cross-convert between all of the supported formats, so a team can move from XML to YAML and back without losing the ability to produce an XML POM.

That last point is the safety net for the biggest risk in this project. A dialect POM is a different artefact from a pom.xml, and a repository with only the dialect file has no plain XML fallback unless someone converts it. Keeping a generated pom.xml in version control, or at least keeping the original one, means the build can always be recovered.

The repository layout shows the shape of the implementation, with one module per dialect, polyglot-atom, polyglot-clojure, polyglot-groovy, polyglot-java, polyglot-kotlin, polyglot-ruby, polyglot-scala, polyglot-xml and polyglot-yaml, plus polyglot-common, the translate plugin and the maven plugin itself. The its/ directory and the poms/ directory hold the integration test infrastructure.

## Mixing dialects inside one reactor does not work

The known limitations section is where the real evaluation happens, and the interoperability paragraph is the first thing to read.

The README says the whole interoperability story has not been worked out, and that currently mixing different dialects within a reactor is not supported. That is a significant constraint in practice, because a reactor is exactly the multi-module build where you might expect a mixed layout, a Ruby POM for one module and a YAML POM for another. The rule is one dialect per build.

The second limitation in that section concerns what happens to a POM that is not XML. A pom.xml will currently not be installed or deployed except for the Ruby DSL and the Scala DSL, and the project says it is working towards this feature for all DSLs.

The third is tooling. Some support in IDEs such as IntelliJ IDEA and Eclipse exists, and the different markup languages are understood by various syntax highlighters, but full integration of the markup syntax and the specific Maven-related aspects is not available. In practice, the IDE sees a file that is not a POM, and the Maven-specific navigation and assistance that a Java developer expects from their IDE is simply not there for the dialect file.

The README also says that, despite the warnings, Polyglot Maven is pretty stable right now, and points to the integration tests for each dialect in the repository and to a separate polyglot-maven-examples project as places to look.

## Release tooling that reads XML will fail

The limited plugin support section is the practical trap for a build team, because it breaks the tools people use on release day rather than the tools people use on ordinary days.

Maven plugins or plugin goals that rely on the XML format are not supported, since they are either attempting to parse the XML directly or modify it in an automated fashion, and neither works with Polyglot Maven. The named examples are the Maven Release Plugin and the Maven Versions Plugin. The README adds an important qualification for the Versions Plugin: goals that do not edit the pom.xml, such as display-dependency-updates, work as expected.

So the failure is narrower than a blanket incompatibility, and it lands in a specific place. A Versions goal that only reports information is fine. A Versions goal that rewrites the version in your build file is not. A release plugin that bumps versions, tags and deploys is not.

The README's position is that fixes would have to be implemented in those plugins, and that workarounds or replacement workflows for most use cases exist. That is the right framing for an evaluation: the question is not whether Polyglot works with Maven, it is whether your release process can be moved to the workaround, or whether your release process is the kind that has to keep operating on an XML pom.xml.

Real-world usage listed in the README includes JRuby with extensive usage of Polyglot Ruby and contributions back to the project, the ruby-processing project, SnakeYAML with extensive usage of Polyglot YAML, and urbanise.com using Polyglot YAML for a strata management platform.

## Conclusion

polyglot-maven suits a team that wants its build model expressed in a language its developers already read comfortably, and who can live with XML-shaped tools failing on their POM. It does not suit a build whose release process depends on the Maven Release Plugin or on the Versions Plugin goals that rewrite the POM. Before you convert anything, check the known limitations section against your own release workflow, and keep a pom.xml in version control alongside the dialect file so you can convert back with the translate plugin.

## FAQ

### How do I enable polyglot-maven in a project?

Edit ${maven.multiModuleProjectDirectory}/.mvn/extensions.xml and add the extension with groupId io.takari.polyglot and the artifact id of your dialect, such as polyglot-ruby or polyglot-yaml. It is a Maven core extension, so it applies to the whole multi-module build and one dialect per reactor is supported.

### Which markup languages can a Maven POM be written in with polyglot-maven?

The available dialects are Atom, Groovy, Clojure, Kotlin, Ruby, Scala, YAML, Java and XML, published as separate artifacts under the groupId io.takari.polyglot. Several of them also allow inlined plugins, and the README names Ruby, Groovy and Scala as the ones that do.

### Can I convert my existing pom.xml to another format?

Yes, the translate plugin converts a POM file with mvn io.takari.polyglot:polyglot-translate-plugin:translate -Dinput=pom.xml -Doutput=pom.{format}. The supported formats are rb, groovy, scala, yaml, atom, java and xml, and you can convert back to xml or cross-convert between them.

### Which Maven plugins do not work with a Polyglot POM?

Plugins and goals that rely on the XML format are not supported, either because they parse the XML directly or because they modify it automatically. The README names the Maven Release Plugin and the Maven Versions Plugin, while noting that Versions goals which do not edit the pom.xml work as expected.

### What are the version requirements for polyglot-maven?

At runtime it needs Maven 3.6.3 or later and Java 8 or later. Building the project itself needs Maven 3.9 and Java 17. The licence is EPL-1.0 and the most recent release listed is polyglot-0.8.2.

## Sources

- [Issues](https://github.com/takari/polyglot-maven/issues)
- [License: EPL-1.0](https://github.com/takari/polyglot-maven/blob/master/LICENSE)
- [README](https://github.com/takari/polyglot-maven/blob/master/README.md)
- [Releases](https://github.com/takari/polyglot-maven/releases)
- [takari/polyglot-maven on GitHub](https://github.com/takari/polyglot-maven)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/takari-polyglot-maven