When I think of Gradle I think of the countless software development shacks where no one can understand or extend the Gradle configuration because someone, years ago, thought it would be cool to be hip and use Gradle instead of Maven, left the company and now nobody is interested in learning it.
Why I Moved Back from Gradle to Maven
131–140 of 172 posts
Re: Why I Moved Back from Gradle to Maven
#132Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no i…
Lack of flexibility means that it will only work for xx% of projects (supply an arbitrary value for xx but other than 100, by definition).
Then what it means, is that 100-xx percent of projects are going to be screwed up.
Not everybody lives in a nice world when the project is a single web application with 4 microservices and a shared library maintanied by a team of 5.
Re: Why I Moved Back from Gradle to Maven
#133I moved from Maven to Gradle about two years ago and I am not going to look back. I understand the arguments made in article and I am the Gradle ninja in my project so I may have subjective view on the whole topic. My points: - Maven requires a lot of boilerplate for everything. Copy-paste. I need to instruct everybody on what to copy, where to paste, and how to edit and what they should not touch under any circumsta…
>Gradle... It's an environment for programmer! >Maven...you have to write your own plugin. Not nice. >If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging You've just explained why I have no interest in Gradle. You're writing one off, undocumented, anonymous plugins, in a weird domain specific language, with debugging tools that aren't very good. Worse, when the Gradle gu…
Yeah, especially code like that:
artifactory { publish { repository { repoKey = version.endsWith('-SNAPSHOT') ? 'libs-snapshot-local' : 'libs-release-local' } } }
In Gradle, this is immediately understandable to everybody. You can't do this in Maven without plugin support or some very protracted constructs.
Sprinkling those small bits makes the Gradle useful. We are not talking about making a beast of a build system, just provide you with an ability to solve your problems.
You may not want or like to learn another tool and that's fine. But don't think that just because you don't see the reason it means its not useful for other people.
Re: Why I Moved Back from Gradle to Maven
#134Earlier quoted context omitted.
> you either expect any user to coerce their case into your model (and hope the plugin is documented, dependencies work (bwahahaha) and is maintained) I find all the cases can be coerced, and it's not even hard. Some users seem to insist on customization for its own sake, "oh I absolutely must call my source folder source rather than src", but Maven does the right thing by ignoring those users, with the result that y…
The case I remember was a couple of years ago. We had a test runner for our JS code that was delivered by our Java webapp. Part of that configuration was the list of flags to a maven plugin. The issue was that we had two orthogonal configuration options that affected the list of flags. Initially, it used HTMLUnit and didn't record coverage statistics. We wanted to record coverage, and also switch to PhantomJS (when i…
Ok, good example of the tradeoff maven makes. My view is: it's worth making that kind of inherently complex case complex for the sake of the comprehensibility advantage that all projects gain from having the entire test runner string in one fixed place where a reader can look for it. Some test plugins do provide a separate "extraArgs"-type config that you can use for that kind of case, but I'm not convinced that it's a good idea.
Re: Why I Moved Back from Gradle to Maven
#135One thing I haven't figured out in Gradle is that (in IntelliJ) in a maven pom, I can command-B to find the pom definition of a parent pom or a dependency. command-B in gradle doesn't do anything there. Anyone know the magic command?
Asking the real questions.
Re: Why I Moved Back from Gradle to Maven
#136Probably unrelated, but Java really needs to fix its Classpath Hell issues. On so many sufficiently large Java projects, you end up descending into the inclusion/exclusion madness with your build files because your app is inheriting `log4j` from 50 different libraries. Or the infamous xerces hell[1]. And fixing that in maven is not pretty :(. [1] https://stackoverflow.com/questions/11677572/dealing-with-xe...
Wasn't Java 9 modules supposed to help address these issues?
No, it is supposed to reduce surface area between modules/jars. Before Java9 library creators could only add "internal" to their packages name and hope end users won't touch it.
The introduction of modules might actually make version hell even worse: https://blog.codefx.org/java/dev/will-there-be-module-hell/
Re: Why I Moved Back from Gradle to Maven
#137Earlier quoted context omitted.
What if two things share a dependency?
Do you mean a conflicting dependency in one of my 5 projects? If so, it's on me to pay that technical debt and fix my own crap. If the dependency doesn't conflict, then my package manager takes care of it.
In the JVM world it's not uncommon to have different sets of versions of the same libraries for different but dependent projects. And it's not a problem, because classloading is hierarchical and so different versions can live side by side even inside one JVM.
And a lot of Java/Groovy/Scala/Kotlin libs are on Maven Central, but not packaged for let's say CentOS/Ubuntu/Debian/etc. So the package manager for JVM is Ivy (ivy2), or full Maven (which is basically ivy + a task runner).
Re: Why I Moved Back from Gradle to Maven
#138Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no i…
> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system…
At least in Maven, the answer here is simple: write your own plugin.
You can do whatever you want, but you're still operating within the confines of the build system so you've not lost the ability to see what's going on.
It's not all that common that I see an "advanced task" that actually belongs in the build, though -- more often I see people who have decided to fight against their tooling rather than working with it.
Re: Why I Moved Back from Gradle to Maven
#139Earlier quoted context omitted.
I'm neither Maven nor Gradle ninja. Just a senior software developer with 15+ years of experience... > Maven requires a lot of boilerplate for everything. Copy-paste I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven > Gradle... It's an environment for programmer To me this…
> > Gradle... It's an environment for programmer > To me this is a counter-argument. When I need to understand project configuration I expect structure, not behaviour. Agreed. Every time I see a build system that lets you write arbitrary code, I shy away from it. Builds should be standardized, not a mess of custom code. Maven lets you write plugins for the case when you need to do something truly custom, but in my ex…
I think the difference between arbitrary code in buildfiles and an obscene zoo of plugins running arbitrary code is rather small in terms of actually understanding the build.
My takeaway from using both maven and gradle is that I would really love to have a build system with emphasis on allowing custom arbitrary code, but only within guiderails that force them into a shape that is easily factored into a plugin if you layer decide to do so. Maybe even with a defined reverse path for unboxing existing plugins back into their inline form (for when you absolutely need a fix/unexpected customization, but can't commit to fully maintaining the plugin)
Re: Why I Moved Back from Gradle to Maven
#140I can see the attraction in a build system based on a proper full featured programming language but I've never been tempted to try gradle because I believe the approach has a fundamental flaw. I.e. that it's impossible for IDEs to reliably extract useful project structure from the build description. Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and more and I believe that any proposed build…
I think that's a fundamental flaw of IDE's, they don't integrate with your development environment ;) Something I just thought of but have yet to try, could we have a build script generate the project structure that an IDE can use and get the best of both worlds? Looking through my VS project files, 50% of it is stuff the make file would be doing, the other 50% is just a list of files and dependencies. So let's say w…
Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files.
But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it. Gradle is complicated by the fact that it's much easier to run custom code that modifies the build during the build (which is why I don't like it so much), but IDEs can still inspect the build model to work out what's going on.