3 ms·

I spent a good 18 years in the Java coding stack. I adopted Maven when they just released version 2 and watched one of its evangelists talk at a JavaOne. Obviou

I spent a good 18 years in the Java coding stack. I adopted Maven when they just released version 2 and watched one of its evangelists talk at a JavaOne. Obviously now it's insane to think about a programming language that doesn't have a dependency manager (even C/C++ has Conan!). After a long time fighting between what I liked best between Maven or Gradle I realized that the only thing I really needed was the parts to build the Java code. Things like Docker, Java code generation and a variety of other tasks you often do for releases, I finally figured out what I needed to do: Make sure everyone on the team can run Bash. From there I could stop worrying about Windows users - Git Bash or Babun or some flavor of Cygwin. And things are even better with Linux Subsystem for Windows. Now we simply have bash scripts that do all our one-offs that often were nightmares to accomplish in Gradle or Maven. Whether it is JAXB or Docker integration every maven/gradle plugin I ever used was 10 times harder than just bash. When you start taking out all the other stuff it started to become clear that Gradle was winning out. With gradle I can build my code and get a variable that represents every JAR I need for a deployment into a Dockerfile containing folder. So that's where I personally ended up liking Gradle more - because I stopped depending on Maven and Gradle to do the other kitchen sink tasks.

kovrik 9y ago
Honestly, I have the opposite opinion. I really don't like it when there are custom bash build scripts. And you have to figure out how they work and what they do. And how to pass additional parameters etc. If you use Maven for your project, then I expect that if I run `mvn clean install` then it will build the project. I think that is the whole point of standard build tools: that you can switch projects easily, run the same command and get the same result, and not waste time learning custom scripts for each project.
- Consultant32452 9y ago
  This is a common problem for programmers in general, not just at build time. Occasionally you will run into a case where the framework you've chosen just doesn't fit. You can try to hammer your need into the framework in some horrific fashion or your can temporarily circumvent it for this one task. Which path you go depends on a lot of factors.
- bonesss 9y ago
  I think FAKE (https://fake.build/ https://fake.build/), hits an amazing sweet spot for this: standardized, predictable, with no sacrifice of programming/platform power when dealing with builds. Project to another, just run "build.fsx" with the desired target -- it will self-download necessary tools and packages -- and you'll get a straightforward standard build. If you want to see the logic, just open it up: build scripts are standard F# scripts Because you're using first-class scripting you get full language power, full component and package management power, full abstraction power, aided by a set of utility methods and tools. At any point things get hairy you can wrap them into a lib, or a full program, with no domain impedance. It's standard code, as learnable as the rest of the F# proj, no voodoo, no black boxes. Heck, you can also load your project and use its libraries during the build. I find myself often using FAKE components in my main solutions to take advantage of its interop and publishing...
koolba 9y ago
I do something similar but with a Makefile as the top level. Every project I work on has a top level default that will fetch dependencies and build the project. Lower level recipes are either one liners that invoke a project specific builder (ex: mvn package) or they invoke a separate bash script. For complicated polyglot projects it works great as each component can use its own native tooling yet the top level is consistent.
lmm 9y ago
> Now we simply have bash scripts that do all our one-offs that often were nightmares to accomplish in Gradle or Maven. Whether it is JAXB or Docker integration every maven/gradle plugin I ever used was 10 times harder than just bash. This is the opposite of my experience. Trying to get consistent behaviour out of bash scripts is a nightmare (every nontrivial bash script has an undocumented dependency on a particular version of some system tool, every time you try to build on a new machine you're rolling the dice). Maven plugins are versioned and (usually) tested, have sane defaults, and will Just Work (provided you're willing to roll with their defaults rather than fighting it).
- jillesvangurp 9y ago
  Funnily, 10 times harder is exactly my experience with most maven plugins. Maven is fine if you stick to compile, test, and jar. Anything beyond that just tends to escalate into madness.
- mgkimsal 9y ago
  > every time you try to build on a new machine you're rolling the dice why not on copies of known-good machines? vm boxes with the same definitions would alleviate almost all of that 'roll the dice' aspect, no?
  - lmm 9y ago
    At that point you've frozen a working image of your dependencies along with a bunch of other stuff, but you still don't have a clear picture of what those dependencies are and how to work with them. Your build works in a vm of RHEL 5 with packages x and y installed, ok, now you need to add a new build step that depends on something that's only available for RHEL 7. So you run the VM generate script (if you can even find it a year or two later) and the build doesn't work. Now you get the same fun debugging experience. Standardising which OS and package installs every developer uses (whether with a VM or just with something like Puppet) means you get to roll the dice less often, but it's still a dice roll whenever you want to change something. And running all your builds in VMs has a cost in terms of performance but more importantly in terms of comprehensibility. If my build is just Maven I can run it in my IDE, then I can push one button differently and run it in my IDE with a debugger attached. If the build is running slowly and I'm not sure why, I can push one other button and now I'm running it with a profiler. Some of that is just an argument for having your build tooling written in the same language you're using for development (if I was working in e.g. Python, I'd be more likely to have a Python IDE and a Python profiler to hand, so would want to use a Python build tool), but even if you're used to working in Bash and C I'm not sure the VM advocates have good answers to how you debug something running in a VM as yet.
commandlinefan 9y ago
> Now we simply have bash scripts Hm - I don't know about that. The biggest issue I found with Gradle was that it offered unlimited flexibility, and inevitably, somebody would mickey mouse sorcerer's apprentice the thing and stick something into the build script that didn't belong there. Although with enough effort you can do that in Maven, too, by the time you get to the point where you understand how to do that, you know better. I can't even imagine what sort of nightmares somebody with the even-more unlimited flexibility of a bash script could conjure up.

kovrik 9y ago

Honestly, I have the opposite opinion. I really don't like it when there are custom bash build scripts. And you have to figure out how they work and what they do. And how to pass additional parameters etc. If you use Maven for your project, then I expect that if I run `mvn clean install` then it will build the project. I think that is the whole point of standard build tools: that you can switch projects easily, run the same command and get the same result, and not waste time learning custom scripts for each project.

Consultant32452 9y ago
This is a common problem for programmers in general, not just at build time. Occasionally you will run into a case where the framework you've chosen just doesn't fit. You can try to hammer your need into the framework in some horrific fashion or your can temporarily circumvent it for this one task. Which path you go depends on a lot of factors.
bonesss 9y ago
I think FAKE (https://fake.build/ https://fake.build/), hits an amazing sweet spot for this: standardized, predictable, with no sacrifice of programming/platform power when dealing with builds. Project to another, just run "build.fsx" with the desired target -- it will self-download necessary tools and packages -- and you'll get a straightforward standard build. If you want to see the logic, just open it up: build scripts are standard F# scripts Because you're using first-class scripting you get full language power, full component and package management power, full abstraction power, aided by a set of utility methods and tools. At any point things get hairy you can wrap them into a lib, or a full program, with no domain impedance. It's standard code, as learnable as the rest of the F# proj, no voodoo, no black boxes. Heck, you can also load your project and use its libraries during the build. I find myself often using FAKE components in my main solutions to take advantage of its interop and publishing...

koolba 9y ago

I do something similar but with a Makefile as the top level. Every project I work on has a top level default that will fetch dependencies and build the project. Lower level recipes are either one liners that invoke a project specific builder (ex: mvn package) or they invoke a separate bash script. For complicated polyglot projects it works great as each component can use its own native tooling yet the top level is consistent.

lmm 9y ago

> Now we simply have bash scripts that do all our one-offs that often were nightmares to accomplish in Gradle or Maven. Whether it is JAXB or Docker integration every maven/gradle plugin I ever used was 10 times harder than just bash. This is the opposite of my experience. Trying to get consistent behaviour out of bash scripts is a nightmare (every nontrivial bash script has an undocumented dependency on a particular version of some system tool, every time you try to build on a new machine you're rolling the dice). Maven plugins are versioned and (usually) tested, have sane defaults, and will Just Work (provided you're willing to roll with their defaults rather than fighting it).

jillesvangurp 9y ago
Funnily, 10 times harder is exactly my experience with most maven plugins. Maven is fine if you stick to compile, test, and jar. Anything beyond that just tends to escalate into madness.
mgkimsal 9y ago
> every time you try to build on a new machine you're rolling the dice why not on copies of known-good machines? vm boxes with the same definitions would alleviate almost all of that 'roll the dice' aspect, no?
- lmm 9y ago
  At that point you've frozen a working image of your dependencies along with a bunch of other stuff, but you still don't have a clear picture of what those dependencies are and how to work with them. Your build works in a vm of RHEL 5 with packages x and y installed, ok, now you need to add a new build step that depends on something that's only available for RHEL 7. So you run the VM generate script (if you can even find it a year or two later) and the build doesn't work. Now you get the same fun debugging experience. Standardising which OS and package installs every developer uses (whether with a VM or just with something like Puppet) means you get to roll the dice less often, but it's still a dice roll whenever you want to change something. And running all your builds in VMs has a cost in terms of performance but more importantly in terms of comprehensibility. If my build is just Maven I can run it in my IDE, then I can push one button differently and run it in my IDE with a debugger attached. If the build is running slowly and I'm not sure why, I can push one other button and now I'm running it with a profiler. Some of that is just an argument for having your build tooling written in the same language you're using for development (if I was working in e.g. Python, I'd be more likely to have a Python IDE and a Python profiler to hand, so would want to use a Python build tool), but even if you're used to working in Bash and C I'm not sure the VM advocates have good answers to how you debug something running in a VM as yet.

commandlinefan 9y ago

> Now we simply have bash scripts Hm - I don't know about that. The biggest issue I found with Gradle was that it offered unlimited flexibility, and inevitably, somebody would mickey mouse sorcerer's apprentice the thing and stick something into the build script that didn't belong there. Although with enough effort you can do that in Maven, too, by the time you get to the point where you understand how to do that, you know better. I can't even imagine what sort of nightmares somebody with the even-more unlimited flexibility of a bash script could conjure up.