3 ms·
One thing you will find in more complicated builds is that, short of writing your own Maven plugins, you will still need Ant scripts or at least some very arcan
by manyxcxi 10y ago
One thing you will find in more complicated builds is that, short of writing your own Maven plugins, you will still need Ant scripts or at least some very arcane incantations of Maven to get the job done. I've used Maven for a long time and the vast majority of my projects are Maven based- for the ones that follow the archetype, Maven is a pretty easy fit. As a matter of fact if you've got an IDE like IntelliJ, it'll build your initial pom.xml for you and keep adding as you bring in libraries without having manually add them.
I have only recently begun using some Gradle builds after I hopped into an open source project that was using them and I'm quite impressed by the ease of it as well as the speed. You can have Gradle do a lot of the tasks you would've done with an Ant script + Maven pom. I'm already impressed with the lack of effort for sub-module builds, I've always found Maven to a pain for getting those working just right. Additionally, when you run the Gradle build daemon locally your builds are WAY faster than running Maven builds. I found the IntelliJ support for Gradle to be very good so far and I am going to continue to try converting a number of my existing projects over to Gradle as time allows.
EDIT: The main thing I really need to investigate with Gradle is what it does that is similar to a parent pom in Maven. We make pretty extensive use of parent poms in order to reduce boilerplate and keep dependency versions in sync, and we use Artifactory for everything.
EDIT2: This [0] Maven vs Gradle breakdown (though obviously pro-Gradle) highlights some areas where Gradle could really make a difference for people.
[0] https://gradle.org/maven_vs_gradle/ https://gradle.org/maven_vs_gradle/
- GeneralTspoon 10y agoRegarding parent poms, you can do something similar in gradle with the top-level build.gradle file. Check out this project for an example of how that works: https://github.com/JakeWharton/butterknife https://github.com/JakeWharton/butterknife
- xirdstl 10y agoWe created a number of Gradle plugins for our common boilerplate. We publish those as a JAR into our internal Artifactory, and they're easily applied to any of our modules.
- rdsubhas 10y agoIn Maven, the only way to share build logic is through a parent POM. Even if only four modules (out of 10) need to share some build logic, the only way is to get it into the parent POM. So in most maven projects, the parent POM is a kitchen sink. Gradle allows to create separate shared ".gradle" files that individual projects can import. This is push vs pull, and makes a world of a difference. So we have one shared "java_service.gradle" and one shared "java_library.gradle", and our submodules just do "apply from: <shared-build-file>". Our root "build.gradle" is intentionally empty with a BIG warning never to add any shared logic in it. This is just one of the reasons. You also see that with gradle, you can do "gradle test" on one submodule and it will compile all other dependencies but run tests only on this module. Maven, on the other hand, if you do "mvn test --pl <module> --also-make", will compile and test ALL related modules. I can keep writing a long list of other stuff. But in the end, Maven is a "Project Management Tool" that tried to do a hundred things, and gets nothing right. Gradle is a proper good build tool.
- lenkite 10y agoThis is not correct. One can import POM's in maven since maven 3.0.x (which is several years old). You are certainly not 'forced' to have build logic in only parent POM's.