5 ms·

>And the whole library/build ecosystem works a lot better Seriously? Maven was one of the things that made me run away screaming from the Java ecosystem.

lmm 10y ago
Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited: every project uses the same source directory layout, every project uses the same release tag format, every project uses the same unit test layout, and so you can immediately jump into any project and be productive. When you want to run random code in your build process it has to be encapsulated as a plugin, which means a) any random logic in the build process is at least ordinary first-class code that goes through your normal code review process, has a versioning and release cycle, can be unit tested etc. b) the slight extra overhead means there's more likely to be one standard plugin for doing a thing, which again means there'll be a standardised source directory etc., rather than everyone integrating thrift or swagger or what-have-you into their build in an ad-hoc and slightly different way. c) often people decide that actually they can live without having function names be capitalised if the build was made on a Wednesday or whatever nonsense they wanted to do to the build, and put their business logic in code where it belongs instead. Beyond that there's a working central repository where all the important libraries are (and it's one of the few ecosystems that actually enforces code signing of all published libraries), and also a free repository server that you can run on-premises (and that's a normal JVM app that runs like anything else in the ecosystem) and use for private publishing and/or to proxy remote repositories to make sure you will always be able to rebuild any previously successful build even if a remote repository goes down. The release plugin enforces good practices by default, e.g. you tag a release and rebuild from that release, ensuring you can always recreate any given release; you may build a -SNAPSHOT which depends on another -SNAPSHOT, which makes it lightweight to make a change to an upstream library and check that it has the right effect on your downstream application (and the first-class IDE integration dovetails very nicely with this), but releases are only allowed to depend on releases, which ensures they're reproducible and immutable. None of this should be hard, and I think other ecosystems are gradually getting it right, but Maven just seems to have managed to make all the right choices and avoid all the pitfalls. You don't hear as much about it as you do about, say, NPM, but I think that's at least partly because it rarely goes wrong, so a lot of the time it's invisible to developers.
- crdoconnor 10y ago
  >Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited That, along with its horrible XML markup abortion, was exactly what I hated about it. Any behavior that was even moderately unusual was a monumental pain to implement. Build scripts by their very nature need to be turing complete because the need for customization isn't rare enough. >Beyond that there's a working central repository where all the important libraries are Python got this 17 years ago, a good 4 years before maven even existed.
  - bluejekyll 10y ago
    Maven is not a build script, it is a declarative build definition system. It is not supposed to be Turing complete, for things that need that customization, as the GP stated, you use extensions. For anyone who likes maven, checkout cargo in Rust. It got everything right, and made build extensions easier to integrate.
  - lmm 10y ago
    > Build scripts by their very nature need to be turing complete. They really don't. The build process should be simple and the same for every project; any actual logic can go in first-class code, that's what it's for (whereas finding out that a file somehow wasn't built, or got substituted before being built, makes for an extremely unpleasant surprise when investigating an issue). I find Turing-complete build systems end up with an analogue of https://martinfowler.com/bliki/SnowflakeServer.html https://martinfowler.com/bliki/SnowflakeServer.html - the "snowflake build", where every module builds slightly differently.

lmm 10y ago

Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited: every project uses the same source directory layout, every project uses the same release tag format, every project uses the same unit test layout, and so you can immediately jump into any project and be productive. When you want to run random code in your build process it has to be encapsulated as a plugin, which means a) any random logic in the build process is at least ordinary first-class code that goes through your normal code review process, has a versioning and release cycle, can be unit tested etc. b) the slight extra overhead means there's more likely to be one standard plugin for doing a thing, which again means there'll be a standardised source directory etc., rather than everyone integrating thrift or swagger or what-have-you into their build in an ad-hoc and slightly different way. c) often people decide that actually they can live without having function names be capitalised if the build was made on a Wednesday or whatever nonsense they wanted to do to the build, and put their business logic in code where it belongs instead. Beyond that there's a working central repository where all the important libraries are (and it's one of the few ecosystems that actually enforces code signing of all published libraries), and also a free repository server that you can run on-premises (and that's a normal JVM app that runs like anything else in the ecosystem) and use for private publishing and/or to proxy remote repositories to make sure you will always be able to rebuild any previously successful build even if a remote repository goes down. The release plugin enforces good practices by default, e.g. you tag a release and rebuild from that release, ensuring you can always recreate any given release; you may build a -SNAPSHOT which depends on another -SNAPSHOT, which makes it lightweight to make a change to an upstream library and check that it has the right effect on your downstream application (and the first-class IDE integration dovetails very nicely with this), but releases are only allowed to depend on releases, which ensures they're reproducible and immutable. None of this should be hard, and I think other ecosystems are gradually getting it right, but Maven just seems to have managed to make all the right choices and avoid all the pitfalls. You don't hear as much about it as you do about, say, NPM, but I think that's at least partly because it rarely goes wrong, so a lot of the time it's invisible to developers.

crdoconnor 10y ago
>Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited That, along with its horrible XML markup abortion, was exactly what I hated about it. Any behavior that was even moderately unusual was a monumental pain to implement. Build scripts by their very nature need to be turing complete because the need for customization isn't rare enough. >Beyond that there's a working central repository where all the important libraries are Python got this 17 years ago, a good 4 years before maven even existed.
- bluejekyll 10y ago
  Maven is not a build script, it is a declarative build definition system. It is not supposed to be Turing complete, for things that need that customization, as the GP stated, you use extensions. For anyone who likes maven, checkout cargo in Rust. It got everything right, and made build extensions easier to integrate.
- lmm 10y ago
  > Build scripts by their very nature need to be turing complete. They really don't. The build process should be simple and the same for every project; any actual logic can go in first-class code, that's what it's for (whereas finding out that a file somehow wasn't built, or got substituted before being built, makes for an extremely unpleasant surprise when investigating an issue). I find Turing-complete build systems end up with an analogue of https://martinfowler.com/bliki/SnowflakeServer.html https://martinfowler.com/bliki/SnowflakeServer.html - the "snowflake build", where every module builds slightly differently.