I’m wondering what kind of build tool people are using these days. I use gradle, I presume most people do, with the odd person still using ye olde maven, but it would be interesting to actually see some figures on this.
I’m writing the part in an asset store where you can copy/paste a gradle link, and would like to accommodate as many people as possible.
0 voters
I use maven in daily work, gradle in personal project.
Nobody uses Ant?
For jME I’m still on ant…
I use Ant quite a bit for builds (and anyone who prefers NetBeans, that’s Ant), but I assumed this was more about dependency management due to the poll options listed, which would mean Ivy for most using Ant. But I voted Gradle. 
I’ll often use Gradle just for grabbing dependencies, which lets NetBeans do its thing with Ant for builds (lets you use NB’s UI build config dialogs). I find Gradle easier than Ivy for dependencies, although you have to use the trick I posted below.
Gradle hasn’t quite won me over yet for actual builds–it’s still a little too “magic/black boxy” for me, and I still have trouble using their massive docs. 
Since Gradle caches stuff into a local repo instead of just tossing jars into a project folder (I suppose it saves disk space, but who cares?), I use a Copy task to move jars into a /lib folder which lets me point NetBeans to jars and source.
I guess it would be rude to mention this but not show an example (last two tasks):
apply plugin: 'java'
repositories {
jcenter()
}
dependencies {
//Only grab binaries
compile 'org.slf4j:slf4j-api:1.7.25'
compile 'org.slf4j:slf4j-log4j12:1.7.25'
compile 'org.apache.logging.log4j:log4j:2.10.0'
compile 'org.projectlombok:lombok:1.18.4'
testCompile('org.testfx:testfx-core:4.0.8-alpha')
testCompile('org.testfx:testfx-junit:4.0.8-alpha')
testCompile('junit:junit:4.12')
//Grab binaries, source and javadoc
compile 'org.controlsfx:controlsfx:8.40.14'
compileOnly 'org.controlsfx:controlsfx:8.40.14:sources'
compileOnly 'org.controlsfx:controlsfx:8.40.14:javadoc'
}
defaultTasks 'deps'
test.enabled = false
clean.doFirst {
delete "${rootDir}/lib"
println "Cleaned ${rootDir}/lib"
}
task devLib(type: Copy) {
from configurations.compileOnly
into 'dev-lib'
}
task deps(type: Copy) {
dependsOn 'clean', 'devLib'
from configurations.testCompile, configurations.compile
into 'lib'
}
Some day maybe I will stop being a luddite and make the full jump to Gradle…
For quick test/development I use the SDK (ant). For actually releasing a build, I use gradle.
if i would have 2 options to choose it will be gradle + ANT(for assets project, just to use IDE for assets)
now i choosed only gradle and i see its 96% currently xd
Wow, me and my company are all maven 
I did not realize so many people here were using gradle. I have barely used it at all, and never for a personal project.
I have not used ant in forever, personally I find it to hard to work with when I need custom stuff done in my builds. I really should start learning to use gradle more, but I always have issues for the gradle dependencies we have in our CI builds on our GitLab server, which has always kept me with maven (plus, I know how to build maven plugins which makes my life a lot easier)
Once you start using gradle it becomes a lot easier. I did find it a bit confusing at first but now it’s so short-hand compared to maven I’d never go back. It’s the default tool for me 
Also, gradle has REAL multiproject support instead of the hacked in not-really-multiproject stuff that Maven has.
meaning, in gradle I can ‘gradle run’ from a child project and it will rebuild only what’s necessary. In maven (my day job), I have to rebuild sections of the tree manually… and 9 times out of 10, I have to clean build that section because maven is also ‘dumb’ about what has actually changed and just leaves it up to javac.
I deal with that a lot. Lots of our projects have batch/bash scripts to do other build tasks because it is a pain to do them in maven
Gradle ease of use for the basic case is no big deal, but I’ve found that if I want to do something non-standard, it’s not always a quick thing to troubleshoot. Tooling support seems to lag behind too, it took awhile before I had a working Gradle plugin for post Java 9 NetBeans. If NB supported Gradle natively, that’d be the day I ditch Ant.
Ant is usually simple figuring out bonkers stuff. With Gradle (Maven same), not necessarily. I try to avoid the temptation to only “code by Google” (or “code by Stack Overflow” these days), using documentation and actually learning how the thing works. It’s slower sometimes, but you end up in a better state. With Gradle, I don’t have that proficiency level yet for doing the uncommon stuff. Admittedly I’ve spent almost no time reading up on the Gradle DSL, so maybe that’s the issue.
I used to be sort of a “Maven hater” (still make fun of it sometimes, when I want to start trouble 
) but I’ve calmed in recent years with Gradle’s rise. Gradle at least brings some things that I can benefit from. XML for builds has always just been weird.
Yeah, similar experience… except I dug in and learned gradle to try to avoid maven. Unfortunately, I did not succeed. That Monday morning “mvn clean install” is always so painful after a whole weekend of never having to do “gradle clean” a single time.
The thing that always bugged me about Maven versus gradle:
“I want to do this slightly odd thing.”
Maven: “You are stupid to want to do that.”
Gradle: “Oh, we haven’t implemented that yet but here’s how you can do it:” (shows you groovy code)
…in the end I switched because instead of writing ANT plugins for my custom stuff, I could just write a few lines of groovy code and reference them in my build.
It does help if you know Groovy a bit, though.
Bottom line, I feel you… but know that learning a bit of gradle is not usually wasted time.
Edit: I’ll add that most of the time I spend in gradle is not “how to do a thing” it’s “how do I do it like gradle devs wanted me to do it”. You can hack in whatever weird stuff you want usually. 
Ah, I also spend above-average effort to “do it the official way” (if there is one), so that makes sense.
Agree it’s worth learning in depth, I just need to spend the time. Been spending most of that energy on Git instead, but probably about time for a deeper dive with Gradle. I do use Gradle for some projects (JME stuff especially), but the built in JavaFX support in NetBeans (all Ant with full IDE integration) is hard to give up.
A shame you haven’t been able to get Maven ditched at work (“Monday morning”). I’m lucky I guess, I have tyrannical “dictator” control at work as a tech/team lead.
Yeah, well, I could push it if I wanted to except it’s not ‘good business’:
Yeah, I figured you were probably stuck in a situation like that. New project time. 
One reason I avoid the big monster apps. It’s a flaw really–I want to like what I do.
Well I haven’t checked the gradle repo, but maven central has a nifty feature for downloading package jars in the browser which is neat for those that don’t bother with build tools at all. So a maven link would probably be helpful.
I’m shocked at how dominant Gradle is over Maven in this poll. Totally cool with it, but also shocked.
Direct download link via Maven Central etc. also useful for me for those times that I don’t want to bother with a Gradle build file at all. SDK users might prefer that starting off.
Yeah, it’s easy to find published jars in maven central or bintray… even just from the “maven coordinates”.
Yeah I thought it’d be 70/30 for gradle/maven, not a whitewash.
The point though is that I don’t have to support 10 different tools. I’m sure they are popular in various circles but clearly not this one 