121–130 of 172 posts
I’m surprised nobody has mentioned buck or bazel in this thread. At Addepar a few years ago, I transitioned a several-100-k LOC Java codebase from Gradle to buck. It was a fairly complex build including Jooq code gen. Build times became much faster and flaky CI issues went away. Today, I’d try Bazel— Buck only exists because ex-Google FB engineers had to recreate Googles amazing Blaze build system. Google has since r…
I work on full-stack product, with iOS/Android SDK element that other people integrate in their apps. Server-side with UNIX boxes: everything works always. Xcode/iOS: we published CocoaPods. It was pain to get to work reliably on laptops/Jenkins b/c of upgrades to Ruby, but if you lock yourself to one Ruby version, and lock the Gemfile, it's mostly OK. At least it's pretty obvious when/why it doesn't work. Gradle: it…
It was common at local JUGs almost 10 years ago, when there was lot of hype around Groovy and Grails.
Even at JSF Days 2007 there were some talks about adding Groovy support to JEE as a means to write session and entity beans.
Nowadays Gradle is the only thing keeping Groovy from completely fading away.
That and Grails maintenance projects.
Earlier quoted context omitted.
Gradle scripts are an undocumented superset of Groovy. It's not just Groovy, it's the fact that there's no consistent way to know what settings and defaults come from where. (And really, why would you know Groovy these days? Is it even used for anything outside of Gradle anymore?)
* Easy to read * Collections tools * Functional programming with closure * Traits * Typed or not * DSL * 100% compatibility with all jars * Awesome framework like Grails and the upcoming Micronaut and SpringBoot * Enterprise software or script, you're welcome. There is a whole world out there.
Nowadays all of that is a synonym to Grails maintenance projects.
Because you don't know Groovy. Simple. Maven it's only in your comfort zone. Bye.
Gradle scripts are an undocumented superset of Groovy. It's not just Groovy, it's the fact that there's no consistent way to know what settings and defaults come from where. (And really, why would you know Groovy these days? Is it even used for anything outside of Gradle anymore?)
I don't see a reason to NOT use groovy in any java project. It makes java so much nicer.
Earlier quoted context omitted.
> 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…
You're assuming that you're around when the team is building out said system. What if you have the misfortune of inheriting a system where there was plenty of rope to go around?
Earlier quoted context omitted.
> 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…
I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time. The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using t…
Confused here. I can't really stop progress waiting on build system features. Extensibility is required like a programming language. Otherwise, you must stop using the build system or build wrappers around it or outside of it making your build even more bespoke than if you used a more flexible system.
Earlier quoted context omitted.
> 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…
I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time. The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using t…
I think this dichotomy, flexibility vs maintainability, reflects build complexity.
Not only do I think the same-language-DSL (a la LISP, as you pointed out), is the 'least bad' choice, I think if we raise our gaze a little the answer here is painfully obvious: how do we handle those issues everywhere else?
In other cases if you need to move files, call some sys commands, structure some data, and express some logic? What if you have to call a webservice with some throttling logic, where is your "build language"? Plop something in a DB? Not to mention that complex builds often have specialized command line apps called by their specialized build langauge.... why?
Complex logic we use programming languages for. Why sacrifice power, components, libraries, compiler-time-checking, and all the rest to use a lesser tool? Full language power, it's The Right Thing.
Earlier quoted context omitted.
Not as easy as using gradle. I've written a couple maven plugins in my time, and I'm so very glad we have gradle now.
Maven plugins still have lots of structure to obey, but you can treat the plugin as a black box very easily. Other people dont need to understand the innards to compose the plugin with other plugins. I'd be hard-pressed to see how you can do that with gradle.
Earlier quoted context omitted.
I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time. The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using t…
> may the PR reviewers determine my fate Confused here. I can't really stop progress waiting on build system features. Extensibility is required like a programming language. Otherwise, you must stop using the build system or build wrappers around it or outside of it making your build even more bespoke than if you used a more flexible system.
If I'm writing code anyways in MyLanguage to compensate for MyBuildScript, why aren't my build scripts written in MyLanguage?
Earlier quoted context omitted.
It may be you are doing plain simple (can be large, but still simple) projects for which Maven is perfectly fine. Gradle is for when you require some more complicated behaviour in your project. For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. I have created a…
Can you supply an online tutorial of this approach using Gradle? ... I'm not sure what to google to find it myself (I don't use Gradle, but it sounds powerful).
Here is a small example I just googled: http://mrhaki.blogspot.com/2013/05/gradle-goodness-extending...
The main idea is to use the language to create another language layer, better suited to the task at hand.