5 ms·

> I mean Maven really sucks Why? I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Bey

> I mean Maven really sucks Why? I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years. 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've written a maven plugin, and the documentation/support was rather poor. I also found myself having to use an older version of various plugin libraries in order to write proper tests for the plugin. It took me a couple of weeks. Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day. That said, it's stable and well known. Gradle seems to have the momentum and increasing mindshare, but you probably won't get fired for using maven.

tootie 11y ago
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 https://github.com/takari/polyglot-maven
- rattray 11y ago
  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>
  - drdeca 11y ago
    It took me until the question marks to realize that the words were repeated. Weird.
- dasil003 11y ago
  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.
- dragonwriter 11y ago
  > 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.
  - mahmoudimus 11y ago
    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.
vorg 11y ago
> 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.
EdwardDiego 11y ago
> 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.

tootie 11y ago

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 https://github.com/takari/polyglot-maven

rattray 11y ago
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>
- drdeca 11y ago
  It took me until the question marks to realize that the words were repeated. Weird.
dasil003 11y ago
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.
dragonwriter 11y ago
> 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.
- mahmoudimus 11y ago
  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.

vorg 11y ago

> 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.

EdwardDiego 11y ago

> 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.