# Maven Escapes from XML

| by Alex Blewitt 4 Followers on Mar 20, 2015. Estimated reading time: 3 minutes |

Maven, the de-facto standard build tool for Java applications over the last couple of decades, has been taught how to process build files that aren't written in XML. Known as polyglot maven, the pom.xml build file can be replaced with a plug-in that effectively knows how to synthesise one from an alternative representation using a different language. The polyglot-maven-examples repository include an Atom based file, a Scala based file, a Groovy based file, and finally a YAML based file, which looks like:

modelVersion: 4.0.0
groupId: io.takari.polyglot
artifactId: yaml-project
version: 0.0.1-SNAPSHOT
name: 'YAML Maven Love'

properties: {sisuInjectVersion: 0.0.0.M2a, teslaVersion: 3.1.0}

Each individual language can provide its own parsing and processing mechanism, and in the case of Scala or Groovy plugins can write in-line code that is executed during build time. This allows individual projects to write snippets of code that may be too simple to expose as a plug-in but not trivial to implement other than an embedded Ant script. It also allows editors with knowledge of language specific syntax to edit the files. This mixes the flexibility of Maven 1 (which supported in-line code written in a language called Jelly) along with the extensions of Maven 2 (which delegated in-line code to plug-ins). Further support is planned, such as the ability to build OSGi bundles directly from the Manifest.MF without requiring a standalone pom.xml file.

The code to implement ployglot maven has been around for a while, but it has been non-trivial to use since it required patching the Maven installation to add support for other pom.xml files. With Maven 3.3, the hooks to support such extensions allow the changes to be added to the project without requiring a specific pom.xml file. Since the release has been pushed, projects like Spring Hateoas have converted their Maven pom to a Groovy version

Normally plug-ins are added to the pom.xml file, but where are they added if there isn't a pom.xml file in the first place? This is where a key change has been made in Maven – the addition of core extensions. By placing a .mvn folder at the root of the project, it is possible to adjust how an out-of-the-box Maven installation runs. For example, having an extensions.xml allows plug-ins to be added to the build (using the core extensions feature), which in turn can invoke the build itself. To enable the YAML build above, a snippet .mvn/extensions.xml would look like:

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

This triggers loading the YAML file and then constructing the Maven project model to enable the build to progress. The content of the file(s) can be processed using any tool; in the case of JRuby, executing a Ruby program to calculate the dependencies and set up the necessary build plug-ins.

By externalising the build process to a specific tool that knows how to generate content, whilst still being able to export the resulting compiled content (with generated pom.xml file), the pom.xml file can be reduced to just representing the runtime dependencies of the project whilst still giving compatibility for other tools that know how to resolved dependencies from the pom.xml uploaded to a repository. This gives the flexibility of Gradle or Ant whilst still encouraging standard processing tools to be exported to a plug-in extension.

It is also possible to use core extensions to add default options to the Maven command-line. For example, if the Maven project requires a larger-than-default heap size, instead of having to specify -Xmx on each invocation (or requiring the user to set up a MAVEN_OPTS or JAVA_OPTIONS variable) it is possible to have a .mvn/jvm.config file at the root level of the project which contains the arguments for the JVM:

-Xmx2048m -Xverify:none -Djava.awt.headless=true


It's also possible to set up arguments that are passed to the Maven command line options, such as invoking multi-threaded builds whilst being less verbose, by adding the following to .mvn/maven.config:

--threads 2C --quiet

Each time Maven is run from the command line, these arguments will be prepended onto the argument, making repeatable builds between developers (and servers) consistent.

The polyglot and core extensions features require Maven 3.3.1 or above, which is available for download from the maven.apache.org site.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Maven is garbage

Too bad maven can't escape the fact it sucks! Of all the projects to come out of apache, Maven is the worse one.

Ruby DSL

There is also a Ruby DSL which is the primary impetus for the Polyglot for Maven release as the JRuby project have been using a pom.rb format for quite some time. They just had to use a custom Maven distribution. I've added a Ruby DSL example here:

github.com/takari/polyglot-maven-examples/tree/...

Re: Maven is garbage

Your comment isn't constructive. I have used Maven successfully for 4 years. It's dependency management is excellent and the rigid build process Is helpful. The plugins are high quality and there are hundreds of them available. There are other tools that may be "better" but Maven is a solid tool for serious development.

Re: Maven is garbage

Your comment isn't constructive. I have used Maven successfully for 4 years. It's dependency management is excellent and the rigid build process Is helpful. The plugins are high quality and there are hundreds of them available. There are other tools that may be "better" but Maven is a solid tool for serious development.

Re: Maven is garbage

A long while ago we could just write code, compile and run. Now we have to essentially write more code to 'build'. The tooling for 'building' is not nearly as friendly as that for compiling.

As a newcomer to a project you just hope the darn build works or you are tasked with hours / days of debugging even if one line is out of place or some version has changed.

Overall we need a better system; one that maybe use type checking at build-time to make it easier.

Maven's Inflexibility Is Its Best Feature

When I hear "Maven is garbage", well...

Earlier today, I tweeted: "Whoever says "#Maven sucks I can't do what I want" has never had to maintain a build where the prev dev could do what he wanted"

And let me point to this recent blog post that pretty well sums it all (comments are a nice read too): timboudreau.com/blog/maven/read
And another post comparing Maven / Gradle on the language themselves (XML / Groovu): wiki.apidesign.org/wiki/Gradle sumed up by this sentence "Gradle teaches you to hack. Maven teaches you to design!".

If you don't like maven xml file, why not choose Gradle directly?

Re: Maven is garbage

I've had to maintain maven over the years at various places and try to build customer's code with maven. Never once was it easy and often when I asked the customer "how do you build?" the answer is "oh person x does it, I haven't done a build in years because it won't work for me."

other tools are better and less stupid. the worse thing about maven is all the maven zeolots who nag open source projects to use it. As a result, it adds needless maintenance overhead and pain that didn't exist before.

As yes, I've tried to make maven work. I've looked at the source and tried to fix stuff in maven 1 and 2. The Maven eclipse plugin was so horrible and buggy it was like stabbing yourself with a rusty butter knife dipped in ebola. I hate maven and all the time I've lost to it!

Re: Maven is garbage

Any sufficiently advanced build system shows problems, especially if there are lots of corner cases. The good think about maven is that building is often just:

mvn package

If the build is more complex than that, it's not maven's fault. If you need tools in a certain place or environment variables pre-configured, you have a non-portable build in the first place.

The key is that builds should work on a developer workstation identically to a server-side build. Projects that fail to set that up will fail whether it's Make, ant, gradle, maven or 'other'.

The final advantage is that all Maven projects look alike; if you've worked in one Maven project, you know where to find the files. That was certainly not the case for Ant builds, where thousands upon thousands of lines would be used to define which folder contained sources, where they should be compiled to, any options that need to be specified either. My experiences of observing large build farms is that all Maven projects tended to work and look the same, whereas each Ant build (and when they were migrated to Gradle, each Gradle build) would end up with thousands of lines of snowflake build steps and be just as complex as the Ant script they replaced.

I've never seen people having problems with Maven builds; on the other hand, I've seen far more people have problems with Gradle builds.

Re: Maven's Inflexibility Is Its Best Feature

I saw many Maven builds that were unreadable because of the people lazy to learn it (biggest problem) but also because how poor its expressiveness is. It winds forever and ever just to tell you the basics. Mostly on dozen of pages. Why can't we have single line dependency coordinates? Why to change a single attribute in a plugin takes 10-20 lines?

Maven doesn't teach anything (maybe copy/paste stuff between modules from my experience). I tried to cleanup maven builds for a couple of years already and I see the same symptoms. Except for dependency management and preferred project structure close to nobody likes it. Maven experts are rare, really.

Finally, when I want to create zip from my project, I rather script it (sh/bat) around maven build, because going the assembly way is just "let's replace this single ZIP command with incredible directory structure with 200 more lines of code in it, shall we?"

Re: Maven is garbage

Alex,

My larger point is that build systems need the same attention and care as we put into compilers and other programming language tooling because - let's face it - its all just code of one sort or another.

Builds are getting increasing more complex (witness devops). To address this complexity many build systems are now using full-featured programming languages.

You are probably a maven expert but most of us are not. I have walked away from maven builds because as an occasional user I could not fix the builds even after several days of effort.

I discovered that SBT (Simple Build Tool - which BTW is no longer simple) has good support from intellij and as a new user I could actually figure out the issues and fix them all by myself.

Funny story. MS recently open sourced MSBuild. Why? Because no one understood its behavior and so the best answer was to put the source out.

Faisal

Re: Maven is garbage by Mark N

If it were someone else besides Peter, i'd probably think the problem was the person, not the tool. But peter has made his point about maven in the past. Look it up before you dump on him. Typically people tend to do happy path things and think things don't have problems (here is looking at you .NET and Java EE too). The problem is when you get off the beaten path. I avoid Maven and use Gradle. But even then ... .

For perspective I suggest using NuGet and MSBuild ... and Git. Maven will suck less.

Is the polyglot effort ready for prime time?

Thanks for this post, Alex. I'm very interested to hear that polyglot Maven has some life in it. When I last looked at the polyglot project, it looked a bit dead in the water. Presumably if Spring HATEOAS is using it, that implies it works well enough.

But I wonder - would you feel safe porting a large project to polyglot Maven? It's something I might consider doing for the day-job, where my team is suffering from too much XML LOC.

I can't resist also weighing in on the interminable debate around Maven, not least because it sounds like polyglot maven might be answer to Maven's shortcomings.

Maven has given us a lot of great stuff - especially the artifact/dependency management pattern - but it mixes too many concerns, has hitherto forced us to program in XML, and is wildly inexpressive. The main mechanisms for engineering common kinds of build operations in a single multimodule project are inheritance (with a complex occlusion/overriding policy not expressed in the XML) and custom plugins. Any reasonably large Maven build requires a developer to maintain a complex mental Maven virtual machine. Gradle - and now perhaps polyglot Maven - helps us to realise that developers should be allowed to use powerful languages to achieve what they want, not forced to use lowest-common-denominator languages just because others have misused power in the past. The old argument about Ant - "look at how messy it was! thank goodness we can't do that" - has always struck me as fallacy.

I must confess I also disagree that we should have to use Maven for platform independence: I think that's positively a bad thing, to have to develop on a platform which is difference from production's. What production application comes to life using mvn:exec? At some level, you always end up duplicating some effort for each platform you target.

Sorry - this is a bit off-topic. Clearly I need to rant elsewhere.

Hi

what about introducing Hocon instead? I found it very useful as a syntax, and the idea of find a way to transcribe maven (or even sbt!) builds with Hocon run in my mind since about a couple of years... do you know if somebody had tinked about this?

Alfredo

Re: Maven is garbage by Seriy V

peter lin, you are inadequate. You can think whatever you want but keep you comments with you. Nobody really cares about you and wants to hear you "genius" and inadequate comments because first of all they are very and very far from being "genius".

Before abusing work of other people please tell everybody what good you have done for the world and why anyone should care about what you say. Have you saved millions of people? Have you found a cure for cancer? Have you done anything really great? Why you think you can behave like this?

I doubt you do understand at all how open source works? Don't like something done by others - do yourself. I bet the main reason of your inadequate behavior is that you feel abused because other people don't recognize your "greatness" and you realize by yourself that you can't do anything good.

There is a good reason why many thousands of people know many open source frameworks including maven. And there is a great reason why nobody knows who is peter lin. Can you realize this???

Re: Maven is garbage

The final advantage is that all Maven projects look alike; if you've worked in one Maven project, you know where to find the files.

So, you can't improve the structure of your project.

Re: Maven is garbage by Seriy V

>So, you can't improve the structure of your project.

Anyone who worked with maven knows that the structure can be changed.
Based on such comments you may think that the most active people discussing Maven are people who never used it or don't know how it works ;-)

Re: Maven is garbage by John M

That is a very demeaning and rude response. Peter wasn't being very useful when all he had initially stated was that "Maven is garbage" and that "it sucks". But he doesn't deserve a complete stranger pulling him down because he may not have "found a cure of cancer".

He never claimed to be this great "genius" just that "Maven is garbage". He later stated it was due to bad experience using Maven for various projects.

Clearly, his philosophy for development needs does not integrate with Maven's. But that doesn't mean he is wrong or that he should be quiet unless he is some great intellectual. His feelings are valid.

Please, remember there are human beings on the other side reading your messages. Did it do any good to respond to him in that way? I think this response to you does good, but trying to advocate for civil discussions on the Internet.

Re: Maven is garbage

So far Peter, you've only pointed out that other people's build processes suck but have yet to point out that in what way Maven has contributed to the suckitude? Maven isn't the greatest, but it's far better than the horror I have endured with Ant. Or even worse, Java projects that still use Make and/or shells scripts. Oh, or even better: using Ruby Rake to build a Java project, that in turn calls Ant and only builds on a specific Mac OS X environment. Now THAT is garbage!

I'll take Maven any day of the week over that mess again.

Re: Maven is garbage

What improvements did you have in mind?

Re: Maven is garbage

Maven is a build tool, not a programming tool.
It emphasizes a well-defined execution cycle, with very handy defaults.
Maven came to sort out the mess of a great ANT script, which was at the time of its creation a maintenance headache.

Now, to say that Maven is garbage, is for those who have never developed beyond trivial applications, and it's starting now.

Of course, changing a tool that has been there for so long is not an easy task, especially because it is the de facto standard.

We expect the MAVEN maintainers to come up with innovative ideas, mainly to remain competitive in the market, and above all maintain their installed base of professional users.

Maven is great yet!

Maven is great yeat!

Maven is a build tool, not a programming tool.
It emphasizes a well-defined execution cycle, with very handy defaults.
Maven came to sort out the mess of a great ANT script, which was at the time of its creation a maintenance headache.

Now, to say that Maven is garbage, is for those who have never developed beyond trivial applications, and it's starting now.

Of course, changing a tool that has been there for so long is not an easy task, especially because it is the de facto standard.

We expect the MAVEN maintainers to come up with innovative ideas, mainly to remain competitive in the market, and above all maintain their installed base of professional users.

Maven is great yet!
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

23 Discuss