3 ms·

The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped

The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. I've developed Java apps since almost the beginning, and am as much of a markup geek as could be, but still hate maven with a passion, and often times do not understand what tf it wants from me. I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. However, I don't want to sound too negative. I can see a perspective for the JVM (Graal/Truffle) as a polyglot runtime where most of the ancient Java stuff is hidden from you, and you're using JavaScript or other non-JVM-only language as a migration strategy to get rid of Java alltogether in the distant future.

lmm 8y ago
> Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. Could you be a bit more concrete? I don't recognize any of your descriptions in my experience of maven. There are probably some bad plugins out there, but as in any system the solution is not to use them. The complete lifecycle is listed in the documentation, and it's all very common-sense. pom.xml isn't meant to be Turing-complete, and if you try to use it like a Turing-complete build language you will get yourself in trouble (as many of the early Ant diehards did). You need to treat it as a declarative config file, no different from e.g. Cargo.toml. > I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. It's just the opposite. I don't expect anyone to want to maintain Ant or Gradle builds in the future, since they can have any kind of crap in them. But Maven builds are forced to be kept sensible; the tool just isn't flexible enough to let you put crap in your build definition, by design. (If you really insist on doing crap you can make a crappy plugin, but your plugin is then forced to be versioned, tagged in VCS etc., so stands a better chance of being picked up by your organisation's normal code quality efforts).
- tannhaeuser 8y ago
  I may be biased by doing freelance work (eg. seeing only crap projects), but almost all customers struggle with fckn maven: migrating freaking jetty-maven-plugin, servlet api versioning conflicts, ad-hoc scripting using ant plugin, shading/fatjar plugins, multiple mvn central listings for the same artifact, fragile local dependency resolution, dozens of pointless submodules. A customer of mine even had a solid 3 week outage when they wanted to setup a product for blue/green deployment based on maven. Makes autotools look like a sane build tool.
  - lmm 8y ago
    > migrating freaking jetty-maven-plugin There's a jetty-maven-plugin? What for? When I use jetty I treat it as a library, embed it in my application, write my own main() and then my application is just a normal application. > servlet api versioning conflicts > multiple mvn central listings for the same artifact These are a genuine problems but they're ones that every mature ecosystem struggles with. Maven has better tooling than most IME - you can use the enforcer plugin to require dependency convergence, and when multiple packages contain the same API you can put exclusions in a common parent. No ecosystem has really solved the problem of package renames nicely, IME. > ad-hoc scripting using ant plugin Yeah don't do that. If people will insist on shooting themselves in the foot, there's only so much you can do to stop them. > shading/fatjar plugin What went wrong there? IME the shade plugin is very good. There are a couple of inherent JVM-level limitations (having to specify transformers for service locator files etc. because of the way the JVM spec is written) but it's hard to imagine any other build tool could do better. > fragile local dependency resolution Not my experience at all - what specifically goes wrong? > dozens of pointless submodules Submodules are cheap. IME when coming to work on a new project it's much easier to understand the build/dependency structure if there are lot of submodules rather than a complex build - e.g. rather than trying to have a custom build phase for generating some RPC stubs or whatever, it's fine to just have them in their own submodule and then it's obvious to the reader what the dependency graph looks like. What's the downside? > A customer of mine even had a solid 3 week outage when they wanted to setup a product for blue/green deployment based on maven. What? How? > Makes autotools look like a sane build tool. Strongly disagree with that one. Autotools has several layers of template/macro expansion that all seem to do much the same thing (so why not just one?) and encourages builds that use arbitrary unversioned command line tools from the host system, meaning you very rarely get reproducible behaviour on a host with a different setup. Maven gives consistent, declarative builds - what's not to like?

lmm 8y ago

> Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. Could you be a bit more concrete? I don't recognize any of your descriptions in my experience of maven. There are probably some bad plugins out there, but as in any system the solution is not to use them. The complete lifecycle is listed in the documentation, and it's all very common-sense. pom.xml isn't meant to be Turing-complete, and if you try to use it like a Turing-complete build language you will get yourself in trouble (as many of the early Ant diehards did). You need to treat it as a declarative config file, no different from e.g. Cargo.toml. > I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. It's just the opposite. I don't expect anyone to want to maintain Ant or Gradle builds in the future, since they can have any kind of crap in them. But Maven builds are forced to be kept sensible; the tool just isn't flexible enough to let you put crap in your build definition, by design. (If you really insist on doing crap you can make a crappy plugin, but your plugin is then forced to be versioned, tagged in VCS etc., so stands a better chance of being picked up by your organisation's normal code quality efforts).

tannhaeuser 8y ago
I may be biased by doing freelance work (eg. seeing only crap projects), but almost all customers struggle with fckn maven: migrating freaking jetty-maven-plugin, servlet api versioning conflicts, ad-hoc scripting using ant plugin, shading/fatjar plugins, multiple mvn central listings for the same artifact, fragile local dependency resolution, dozens of pointless submodules. A customer of mine even had a solid 3 week outage when they wanted to setup a product for blue/green deployment based on maven. Makes autotools look like a sane build tool.
- lmm 8y ago
  > migrating freaking jetty-maven-plugin There's a jetty-maven-plugin? What for? When I use jetty I treat it as a library, embed it in my application, write my own main() and then my application is just a normal application. > servlet api versioning conflicts > multiple mvn central listings for the same artifact These are a genuine problems but they're ones that every mature ecosystem struggles with. Maven has better tooling than most IME - you can use the enforcer plugin to require dependency convergence, and when multiple packages contain the same API you can put exclusions in a common parent. No ecosystem has really solved the problem of package renames nicely, IME. > ad-hoc scripting using ant plugin Yeah don't do that. If people will insist on shooting themselves in the foot, there's only so much you can do to stop them. > shading/fatjar plugin What went wrong there? IME the shade plugin is very good. There are a couple of inherent JVM-level limitations (having to specify transformers for service locator files etc. because of the way the JVM spec is written) but it's hard to imagine any other build tool could do better. > fragile local dependency resolution Not my experience at all - what specifically goes wrong? > dozens of pointless submodules Submodules are cheap. IME when coming to work on a new project it's much easier to understand the build/dependency structure if there are lot of submodules rather than a complex build - e.g. rather than trying to have a custom build phase for generating some RPC stubs or whatever, it's fine to just have them in their own submodule and then it's obvious to the reader what the dependency graph looks like. What's the downside? > A customer of mine even had a solid 3 week outage when they wanted to setup a product for blue/green deployment based on maven. What? How? > Makes autotools look like a sane build tool. Strongly disagree with that one. Autotools has several layers of template/macro expansion that all seem to do much the same thing (so why not just one?) and encourages builds that use arbitrary unversioned command line tools from the host system, meaning you very rarely get reproducible behaviour on a host with a different setup. Maven gives consistent, declarative builds - what's not to like?