long short story: I’m going to start by Casus next week (Scenery and Sciview) and I’d like to suggest Gradle as building tool and dependency manager to the sciJava community.
Why? I’ll be honest, simply because I’ve been using it all my career, I really never did something serious with Maven. The first thing, at the time, which put me off was the xml and since then I always sticked with Gradle.
But I do totally understand that this has to be seen and analyzed professionally in order to be taken seriously, and in hindsight, I can see I took, luckily, the right decision at the time.
The main reasons to choose Gradle over Maven are essentially: flexibility, performance, user experience, and dependency management.
This post follows a discussion on the Gradle Slack channel and I’m going to report here the most interesting replies since some of the sci people, who are interested in this, might not be interested joining the channel just to read them, like I was suggested on the scenery Gitter channel (definitely too many channels around ).
Let’s start right away with the Curtis’ critic:
My take on Gradle in general is that it is a step backwards from Maven, because it allows people to move away from declarative and back to imperative in dangerous and fragile ways. But I appreciate that it certainly can be more powerful.
Which triggered the following meditations:
Alex Nordlund (github com deepy)
I agree 100%
But I’m also yet to see a fully declarative maven project in the wild
And whenever people ask me about maven they tend to try and want it more imperative, and the moment you got antrun in there you might as well go for gradle and save yourself the headache
Personally I think your best bet is to find a case where something is difficult to do in maven, then take the time to port it into gradle and use that as an example when pushing for improvements
@ctrueden, in this regard, could you list which are/were your pain points, if any?
Björn Kautler, (github com Vampire)
He is imho totally right with all, except for the “step backwards”, instead it should read “step forwards”.
In my opinion Gradle takes the best from Maven (convention over configuration) and Ant with Ivy (the power to easily write a build that does what you want instead of forcing you to jump through ugly hoops)
and adds some amazing more features like the Gradle wrapper, build output cache, Java compile avoidance, many others.
You can also do imperative work in dangerous and fragile ways with Maven by simply writing your own plugin that does bad things or by using antrun.
But well, you can abuse any system always.
So you should always consider what you are doing and whether you should do it that way, that’s simply how software development works.
Remember, it is a tool for software developers, not for managers.
There is no good reason to force software developers to bend into very tight ways a tool maker thinks makes most sense, when you can also provide good conventions and defaults but preserve for the user the power to bend the tool to his will which is how it should be imho.
Björn helped me a lot of times and he proved to be quite experienced. I trust him and I give his point of view a lot of confidence.
Daniel Lacasse (github com lacasseio)
As some mention, finding the bottleneck in term of performance, pain point and developer productivity is your key to make an accurate assessment of the validity for a migration to Gradle. The migration doesn’t have to be a all or nothing. Partial migration or even wrapping the maven build to allow Gradle to drive the build process is a good approach to the problem. Regardless, another good point to consider is the expertise. If most build engineers knows Maven but not Gradle, then it may be a bad idea to migrate given the lost in productivity this may cause. It’s a though call to make, you need to gather more data to support your case.
I totally agree especially with Daniel on the migration point, which can be totally partial of course. I’m trying first with Scenery (and Sciview), we could analyze these as showcases and then draw our conclusions. Although a full Gradle conversion has its benefits, such as aligning versions natively, kind of what already happens nowadays with the parent
Andrey Mischenko, (github com gildor)
I kinda agree with this comment, having declarative build script is nicer than imperative, but I would say that it completely abstract idea, which really doesn’t make Maven better or Gradle worse
I know Andrey the longest and trust him a lot, his concept is also shared by Vladimir, right after
Vladimir Sitnikovm (github com vlsi)
I migrated Apache Calcite build from Maven to Gradle, and here are my findings:
- No-one ever raised “declarative vs non-declarative” thing
- Everybody said “it will break everything”
- Many said that Maven-based build evolved for very long time, so it would take ages to migrate
The pain-points for me were:
- Project loading to IDEA. Calcite uses JavaCC to generate parser from Freemarker templates, so it was like “you need to execute
mvn installbefore the project is importable to IDEA”. Of course, switching between branches was painful;.
- Incremental compilation/jar was not really working with Maven. The project used lots of profiles like “skip this, skip that”
- It was hard to “just build the jar” or “just run tests in core module”. Maven executes Checkstyle, JavaDoc, etc, etc, so building jar spent noticeable time on building irrelevant things.
- Integration testing was hard. Maven doesn’t support declaring project version once, and it still requires to duplicate it all over the pom files. If you need to create a branch and publish it under different version, then you are out of luck. You edit lost of poms.
Now the migration to Gradle was done, and it was like, ok, it just works. There are contributors/committers who know nothing of Maven , and now they know nothing of Gradle . The build just works for them.
An (un-)expected consequence of the migration was that some validations were missing. For instance, the Maven-based build was configured to fail on javac warnings, and I missed this setting when migrating to Gradle. So the code did contain some violations by the time -Werror was re-added.
In general, I agree one needs to understand the pain-points and use-cases before doing the migration.
This is, imho, really a valuable reply. His experience shows like the “declarative vs imperative” dualism exists actually only “on paper”, that is it has no practical implementation in reality.
That’s it for the moment, I wanted to write this earlier but I didn’t have time.
I hope to ignite some interesting thoughts about.
Ps: corresponding github account not as link because I’m new and I can’t post more than 5 links…