31–40 of 168 posts
Instead, you want general purpose language that builds the build dag using the build system as a library. This gets you control and customisability for free, and you can still get reuse through code libraries.
I don't hate Maven, and I haven't left it yet. But he is absolutely correct about the key observation: a basic tool with "plugins" is simply NOT the way to create a build tool. A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it.
So...the way that you do that in Maven is to create a plugin, which is very easy to do. There's your full flexibility, as soon as you want it. Your plugin has to play by the rules, which is a good thing. Maven's useful for more than the beginning of a project. If you're working on real-world software, you're probably not the only person who has to understand your bespoke build, if that's the way that you've chosen to…
I'll take rigid maven any day. Much preferable to some cobbled together build system that is undocumented and hard to reliably reproduce. I'm curious what people are doing with Maven that they manage to get into such a fight with it? Although to be fair, due to issues in its dependency resolution mechanics, it can pull in incorrectly versioned artifacts without ever telling you anything.
I totally agree with the article. I love somethings about maven but XML is a pain to work on. I am thinking that a build system can be built on top of Java. But Java for shell scripting has some drawbacks that can be alleviated. I am working on these little tool to use regular java for shell scripting, it is auto compilable and it has better abstractions for file manipulation. https://github.com/huherto/jashi
I'll take rigid maven any day. Much preferable to some cobbled together build system that is undocumented and hard to reliably reproduce. I'm curious what people are doing with Maven that they manage to get into such a fight with it? Although to be fair, due to issues in its dependency resolution mechanics, it can pull in incorrectly versioned artifacts without ever telling you anything.
I've never understood the hate for it either. It's a relatively thin wrapper around Javac for defining your dependencies and implementing a standard compile, package, test, deploy lifecycle. In the bad old days you would just half-implement the same thing in an ad-hoc way.
Not a fan.
I don't hate Maven, and I haven't left it yet. But he is absolutely correct about the key observation: a basic tool with "plugins" is simply NOT the way to create a build tool. A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it.
A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it. I've never seen a situation like this - but perhaps I've lived a sheltered life. Can anyone give me an example of when this would be a good design decision?
OR
You're reading a file and using the details in that file to control your build.
OR
You need to loop through a set of properties and apply a specific update to each value before the build.
OR
You need to invoke complex build logic based on the platform you're building for (nested ifs).
etc.
There are lots of odd situations you end up in with real projects.
The flexibility this provides comes at the cost of build complexity though.
Obscure syntax and odd custom DSL's (>_> cmake, make, powershell) are bad because they introduce complexity and destroy the readability and maintainability of the build.
You basically need a test suite for your build code to make sure it's building correctly. Terrible.
...but, necessary. I'm not a java guy, but writing C and C++? You need to do this stuff all of the time. scons or cmake really make life a lot easier than trying to force Makefiles to do things with their obscure lambda syntax.