Hacker News Reader

> Beyond that, we used to find ourselves in dependency hell with maven pretty frequently

You'll hit that with Gradle, Ivy, Leiningen, SBT and Buildr too.

> The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.

I'd also call that it's biggest strength. Maven POMs are only ever declarative. I've never hit a FOSS project using Maven that I couldn't build, but I've hit plenty using SBT or Ant that I had to tweak to build.

> I've written a maven plugin, and the documentation/support was rather poor.

I had the same experience with Gradle's DSL documentation, although having a look at it now, they've dramatically improved it since then.

> Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day

"Probably"? "Thrown in"? Perhaps you can cut and paste build scripts between Gradle projects, but write anything more than "a few lines" in Groovy and you're looking at huge maintenance problems, like something that evaluated as ["abc", "defg", "hij"] suddenly becoming ['a', 'b', 'c'] for reasons that become apparent only after hours of printing debug messages.

I think that calling something verbose and unreadable is an oxymoron. XML is very explicit about what each field is labeled. Having an XSD means you always know what field is available where and what type of values are permitted. BUT, if you're still not happy, there's always polyglot maven[1]

[1] https://github.com/takari/polyglot-maven

Why why why do do do you you you think think think that that that a a a language language language that that that was was was verbose verbose verbose could could could not not not also also also be be be unreadable unreadable unreadable ?<question> ?<question> ?<question>

It took me until the question marks to realize that the words were repeated.

Weird.

> I think that calling something verbose and unreadable is an oxymoron.

Verbose and unreadable are not contradictory descriptions. In fact, they are more complementary descriptions -- there is a reason that in natural languages one of the most frequent recommendations for clear and readable writing is to be concise.

Excess verbosity is bad for readability.

Indeed, but it could be argued that excess verbosity might be better for long-term maintainability. Not that I'm defending the topic at hand here: XML as a configuration language.

Interesting you say that because I feel that XML is a bit oxymoronic a priori. They wanted something both human and machine readable, but fails to be great at either.