4 ms·
my organization's goals for java builds are consistency (we want to be able to build deterministic jars), reliability, and playing nicely with IDEs via tooling.
by maximente 7y ago
my organization's goals for java builds are consistency (we want to be able to build deterministic jars), reliability, and playing nicely with IDEs via tooling.
given that, as far as i can tell, there's nothing so compelling that it's worth switching over your project or organization. the tooling around maven is so good, and the inertia so strong (for my organization anyway), that there's no real incentive to switch.
we've found that non-maven developers grumble a lot when forced to use it but then find the system, while verbose, is really solid. we are certainly not willing to throw that all away to play with google's latest cool thing.
- pjmlp 7y agoI grumbled a lot against Maven when my employer at the time decided to throw away our Ant build for Maven, considering that: - We actually made good use of Ant tasks and macros for having convention over configuration build infrastructure - Maven was still on 1.0 beta releases, with incomplete support for the plugins we required However this was more than 10 years ago, and nowadays I am yet to find something that beats Maven eco-system, specially given that I don't suffer from XML allergy, rather it is my favorite configuration format. I cry a little beat every time I have to wait for Android Gradle builds. Guess what, the upcoming Android Summit is enjoying yet another Gradle performance improvements talk. They can't get enough of them.