I don't understand why this is still a matter of discussion after so many years of blood and tears. Maven is dead, everyone else is moving to Gradle (Spring, Android, Hibernate, etc.).
I have been using Gradle now for almost 3 years and I can't be happier. The support is great, they roll out new features at a regular pace, it's fast and incremental build WORKS.
If you work in Java and you are still stuck with Maven, please, take a look at Gradle.
> If you work in Java and you are still stuck with Maven, please, take a look at Gradle.
or ivy? i really haven't spent a lot of time toying with the various build systems. i tend to use ant until manual dependency management becomes ... unmanageable, then maven because i've apparently been brainwashed (i.e. i heard that they use maven at a lot of not-so-bad companies like thoughtworks).
after the article, i do like the suggestion of ivy+buck, neither of which i'd paid attention to before below the clamor of gradle trampling upon maven. before starting considerations along the lines "this software does not do X" or "it does X wrong," what about asking "what's a reasonable task for a single tool?" or more specifically,
"do we really want dependency management and builds handled by the same program?" my impulse is always to go for things that are as modular as possible, but perhaps the reflex response of "no" isn't correct for some reason obscured by lack of experience with the particular problem domain.
Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible dependency engine.
Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle.
Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
> but they decided to roll their own Ivy/Maven compatible dependency engine.
I'd heard about that...as a non-Gradle Ivy user, when they started this, I asked two of their devs if they were going to basically write an "Ivy v2", submit their improvements/patches back to Ivy, etc.
Their response was, paraphrased, "absolutely not, we're building our own thing that is way more awesome and are not interesting in sharing". Which I found disappointing.
I know a clean break is easier, and that the Ivy codebase likely needs it, but Ivy could really have used their focus, and I think it would have benefited the wider Java ecosystem (as many non-Maven builds use Ivy to talk to Maven repos) instead of just Gradle itself.
havent had a problem ivy and ant didn't tackle relatively gracefully yet. I'm only using gradle because all the cool kids are but tbh I'm not really a fan of groovy. I wouldn't ever use the language outside of gradle and thats a bad sign to me.
I looked at all these tools... Then carried on using Makefiles. Seriously, people, building has been a solved problem for decades. Let's all stop fooling around and concentrate on actually writing code!
Well, I use VIM to write Java/Scala/Groovy/Python code but unfortunately large, complex projects do exists and the java ecosystem is particularly good at making things more complex that they need to be.
A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
I don't mean how do you version a Makefile, but if your project depends on 6 libraries (with various version requirements) each with their own sets of dependencies, how do you use Makefiles to download & install all of them?
It depends. For tracking released versions, just let the Makefile download (wget,tar) and build (./configure,$(MAKE)) it. For tracking repo revisions use the VCS (git-submodule,git-subtree).
Ah, I see. Well I don't get involved in projects as Rube Goldberg as that. The 3rd party libraries I rely on have stable interfaces, and current-version is always preferable.
Oh right, then yeah Makefiles are the way to go :)
I'm not sure I'd call those things Rube Goldberg, it's just about depending on small libraries and having a reproducible build if it gets checked out on a CI machine and run.
As always, all about choosing the right tool for the job. If you can solve it cleanly with something simpler then you probably should. Something like Maven should only be used if you're really sure you actually need it, because otherwise it'll be a pain in the arse.
Having said that, splitting up "building" and "dependency management" can make things much simpler. Pip (python dependency manager) is incredibly simple, with the same kind of interface as apt, and if you've got a file with a list of dependencies you just tell it to install all of those. Then you can use whatever you want for the build process itself.
The "this is code but you have to write it as correctly-formed XML" bit is whacky. OTOH, as syntax goes, it probably beats syntactically-significant varieties of whitespace.
> The "this is code but you have to write it as correctly-formed XML" bit is whacky.
that's all over the java ecosystem, though, not just build tools: android and (i think?) spring both use several types of xml files to build. not saying it's not whacky, but it's def. prevalent.
In the Tools category, Gradle is "Adobt", while Maven is on "Hold". You can read the full report but I'll exert the relevant section:
"Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex."
They had a more elaborate explanation in previous editions.
In many enterprises we work for, Maven is still in the "to adopt" phase.
Having said this, I am also an Ant guy for simple projects. Too many scars from an Ant -> Maven migration. All pom.xml files ended up more complex than the original build.xml files, as Maven did not have proper support for the way the build was working before.
Ironically the biggest pain with Ivy is that 99% of your dependencies will be pulled in from Maven oriented sources, so you still have to deal with Maven's deficiencies around dependency configurations.
No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you want incomprehensible build files ala Ant, choose Gradle. If you want standard build files and a rich ecosystem, choose Maven.
Gradle's purpose is to muscle in on the consulting / conference market for Ant, just as Grails's purpose as wrapper around Spring and Hibernate was initially to muscle in on their consulting businesses. Now they've hooked in enough users, their bait and switch business strategy is now to screw them for as much money as they can.
So if you use Gradle now, you'll pay the cost later on after Gradleware is sold to some GE or VMWare or EDS or Oracle.
Yeah, no. Gradle is really nothing like Ant. A bad build script author can use it to write build scrips that look like Ant with curly brackets, but then you can write COBOL in any language. If you take the ten minutes to learn how Gradle actually works, then you don't end up with scripts that are like Ant.
Advocating Maven over Gradle is just a joke. I routinely do things in Gradle scripts that would require writing an whole new plugin to do in Maven.
Even for strict java builds, I've been using 'sbt' (the Scala Build Tool). It really is the successor to gradle, in many regards. Not sure you've tried it as one of your alternatives, but I'd implore you to give it a try.
Ant user here. Ant is Turing-complete, which serves as an object lesson in "can" versus "should". I have actually had cause to program in Ant - because that was the right place for the complexity in question - and would characterise it as what COBOL would look like written as correctly-formed XML. Oh the verbosity!
To be fair, I'm doing things that are actually bad and wrong. (At which point ant-contrib is your last friend.) Ant does its actual job - makefiles for Java - pretty well once you know it. It's fine, y'know, probably pretty much complete.
Here's Netflix Exhibitor (which I wrote): https://github.com/Netflix/exhibitor - the developer who wrote the build scripts did an incredible job. I'm very impressed. However, I don't comprehend it. Note: this was previously in Maven and had exactly 3 POM files.
To my eyes, the build scripts are pretty clear. I like the way the scripts are nicely organized using 'apply'. Maybe the only script that may look complex to someone starting with gradle is 'convention.gradle', but again, nothing impossibly hard to grasp for a developer.
I am not able to maintain these build scripts. This is the problem with DSLs in general. Maven isn't great, but its strength is standardization. I can look at any Maven pom and know what it does and make changes to it.
I have been using Gradle now for almost 3 years and I can't be happier. The support is great, they roll out new features at a regular pace, it's fast and incremental build WORKS.
If you work in Java and you are still stuck with Maven, please, take a look at Gradle.