11–20 of 24 posts
Earlier quoted context omitted.
Maven as always. I don't suffer from XML allergy, and Gradle is Ant all over again. Worse, because it relies on a slow scripting language, or having to go through Kotlin, plus a background deamon.
And for those that are allergic Maven 4 will offer alternative file types via extensions!
Absolute majority of people I witnessed using Gradle (myself including) approached it with almost religious terror. Making a change - any change - is akin to playing Russian Roulette, except all chambers but one are loaded. Change one directive - and your build breaks in most weird and incomprehensible ways.
And then there is the whole notion of stability (I mean "contract stability.") Almost every single release of Gradle breaks things in some subtle ways. I can take a project from the olden UNIX days with its Makefile and that Makefile will work in gmake in the freshest Linux distro, using gmake release that was produced multiple decades after Stu Feldman's make. It doesn't require a very specific version of libc or kernel. Because it is 1. Written portably and 2. It treats its behavior (jokes about using the Tab character aside) as a contract and it doesn't violate it just because some poorly educated software engineer decided that it would be a good idea to change the behavior in the upcoming release.
I think any complicated build system will eventually devolve regardless of the build tool if it's not properly maintained; the variability of the required tasks is just too high.
Gradle does seem to be moving fast with regards to Java support in general changes and improvements in the build tool. It takes effort to keep up, but it's worthwhile.
Earlier quoted context omitted.
Maven as always. I don't suffer from XML allergy, and Gradle is Ant all over again. Worse, because it relies on a slow scripting language, or having to go through Kotlin, plus a background deamon.
I'm by-and-large fine with XML, having used it for many a year; however I really like working with XML when I can use Guile's SXML layer. For Maven it's not that important because POMs are simple enough, but for more complex things it's nice having a useful tool. I actually don't mind Ant very much, but I haven't had good luck using Ivy for dependency management. Maven's been very nice in the decade and a half I've u…
Eventually Maven grew on me, however I would rather go back to Ant than deal with Gradle, the time using it when I did Android development a few years ago, was more than enough.
Almost 40 years of software engineering experience - and I hate Gradle more than I would consider reasonable. In fact, I consider Gradle the absolute worst software system out there. Absolute majority of people I witnessed using Gradle (myself including) approached it with almost religious terror. Making a change - any change - is akin to playing Russian Roulette, except all chambers but one are loaded. Change one di…
What I hated most about Gradle is that groovy is untyped. You'd make a change and wait for your build to complete only to find out minutes later that you made a typo or some other innocuous mistake. Glad they introduced Kotlin DSL.
I didn't notice the breaking changes much when we heavily used gradle. Gradle also comes with gradlew, which bootstraps your gradle project with the exact gradle version that is needed to build that project, so you can take an old gradle project and build it regardless of all those breaking changes that you mention.
Almost 40 years of software engineering experience - and I hate Gradle more than I would consider reasonable. In fact, I consider Gradle the absolute worst software system out there. Absolute majority of people I witnessed using Gradle (myself including) approached it with almost religious terror. Making a change - any change - is akin to playing Russian Roulette, except all chambers but one are loaded. Change one di…
Almost 40 years of software development and I think you're overlooking the strength of Gradle. Before Gradle if you wanted any kind of build step that was slightly outside of the norm you had to roll your own maven plugin or god forbid try to script something with ant in xml. Using a DSL in a scripting language was a smart move. What I hated most about Gradle is that groovy is untyped. You'd make a change and wait fo…
Earlier quoted context omitted.
Almost 40 years of software development and I think you're overlooking the strength of Gradle. Before Gradle if you wanted any kind of build step that was slightly outside of the norm you had to roll your own maven plugin or god forbid try to script something with ant in xml. Using a DSL in a scripting language was a smart move. What I hated most about Gradle is that groovy is untyped. You'd make a change and wait fo…
Friction made people think if they really need this custom step, now every single gradle project has a lot of poorly thought out custom stuff, often something which doesn't belong there.
Just like being weightless is fun - until you need to go to the toilet.
Friction or gravity in systems like this is a feature not a problem.
Gradle is really powerful if you know what you're doing and you take the time and effort to keep your build optimized, sane, and working. I recently built a Gradle plug-in that allows us to build native components on a remote system (z/OS) and integrate these tasks and artifacts with the native Gradle model so that Gradle takes care of caching and parallel task execution. I'm sure this is possible with other build to…
But isn't the key job of a build system to 'just work'.
Ie it's executable documentation of how to build/test the software.
ie really shouldn't need constant maintenance, especially if the code hasn't changed.