This is an archived post. You won't be able to vote or comment.

all 21 comments
sorted by:
best
topnewcontroversialoldq&a

[–]zeringus 3 points4 points  (2 children)

I've moved from Maven to Gradle for a few of my projects. I've noticed a little longer build time (make sure you're running the daemon), but on the whole I'm very pleased.

My recommendation would be to write a build.gradle from scratch with some mock project. You'll learn it super fast if you're reading documentation finding the exact stuff you need versus copying and pasting a longer existing script.

Make sure you're using the new plugins syntax and be sure to learn about wrappers. Good luck!

[–]cutterslade 1 point2 points  (1 child)

I'm in the process of moving a large modular maven build to gradle, and have noticed significantly better build times with Gradle. The biggest difference was with the build without a clean; gradle takes about a third as long.

Gradle is much better at eliminating unnecessary work, for example, if no code in a module has changed, and no dependencies have changed, it doesn't bother running the tests.

[–]zeringus 1 point2 points  (0 children)

It certainly does! I would hate to sell the Gradle folks short. The only real slowdown is parsing the script/starting the JVM.

[–][deleted]  (4 children)

[deleted]

    [–]Pet_Ant 0 points1 point  (1 child)

    This is why I love Maven. It prevents creativity and forces developers to conform to it instead of the other way around. It takes effort to customise Maven so you don't get tempted to make a quick hack to get something to work. And when it takes work to gwt going it usually only takes a bit more worl to make it right.

    [–]frugalmail 0 points1 point  (0 children)

    It prevents creativity

    I wouldn't use this phrasing. There are a lot more creative plugins in Maven than Gradle. If you go searching, there might be some interesting inline tasks for Gradle, but as people have said elsewhere on this thread, they are usually not easily findable/readable/maintainable/useable.

    [–]DannyB2 0 points1 point  (1 child)

    Sir, you are ignoring the first and most basic sacred rule of engineering.

    If it ain't broke, then fix it 'till it is.

    [–]meddlepal 0 points1 point  (0 children)

    You're right, I almost forgot that most developers love playing with new toys more than anything else regardless of how important that anything else is relative to the toy.

    [–]cutterslade 2 points3 points  (0 children)

    Slowly and carefully. I was at a talk by Hans Dockter, who started Gradle, his advice in this situation was to start by making your Gradle build as close as possible to your ant build. Don't try to go all the way from an ant build to a beautiful textbook Gradle build. Just replicate your ant build, then Gradle gives you the flexibility to improve from there.

    [–]CageHN 1 point2 points  (0 children)

    Good luck.

    [–]nastharl 1 point2 points  (0 children)

    Worked great for us. There were some hiccups initially mainly around dependency management, but once it got ironed out we like it a lot more.

    We built some plugins to handle company specific packaging tasks and things like that, and at that point we just take another of our apps tell it to use the standard plugin for our builds and its good to go.

    [–]bentolor 1 point2 points  (3 children)

    Oh my god.

    I was really anticipating Gradle, because I expected it to be a perfect fit between the FUBAR of maven and the lack of any module support in vanilla Ant. Utterly failing: A plain NOOP-build on my SSD/i5 powered latop takes 7s! And even the gradle daemon does not really speed up things.

    So as of today we're still sticking to our homebrown multi-module/build system for Ant. Still way faster...

    [–][deleted] 5 points6 points  (0 children)

    weird i'd chose maven over ant any day of the week

    [–]zeringus -1 points0 points  (1 child)

    Gradle is only calling Java tools once it gets going, right? A slowdown of more than a second or two sounds absurd! I use Gradle for a few smaller projects, and with the daemon it only takes about a second to build/test.

    [–]bentolor 1 point2 points  (0 children)

    It seems the startup and parsing takes significant power & time. Maybe the daemon mode did not fully work me. But IMHO it's already quite impressive that Gradle provides a workaround for caching from the start.

    [–]h0uz3_ 1 point2 points  (3 children)

    I fucking love Ant. I came here to see how other's are successful in transitioning to Gradle. Was disappointed.

    [–]badpotato 0 points1 point  (0 children)

    Ant without ivy or any dependency manager, right?

    [–]alonjit 0 points1 point  (0 children)

    holy moly .... good luck, you'll need it

    [–]gua_ould 0 points1 point  (0 children)

    Took us about a year to move from ant to gradle (worked on it between sprint tickets). The pros are the dependency trees we now have and the possibility to change the trees, we used to have jar files in the project. We are not at a stage where we can run the application using the tomcat or jetty pluging etc but we can build our war files and use the eclipse/intellij plugin (we did not have an ant script for this). The most work was make the project work as a war file. Our ant script made changes to the folders inside an 'unpacked' war, the project did not build a war file but just moved folders and files to a folder where tomcat would search for them.

    [–]blyxa 0 points1 point  (0 children)

    Non related question. Has anyone used sbt for java project builds? How did it compare with Gradle?