The usual backstory is that the old thing was cobbled together over a period of time while the requirements shifted about underneath it. The new thing appears to be "more awesome++" because the requirements are fixed at that point in time. Inevitably, the new thing is forced to cope with changing requirements and the cycle repeats.
Why Everyone Eventually Hates or Leaves Maven
61–70 of 168 posts
Re: Why Everyone Eventually Hates or Leaves Maven
#62"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…
This is so right that I feel like I live in a different universe from someone that wants to write code in their build system. If you do write your own build system, make sure it outputs a pom.xml file so I can still use maven.
Re: Why Everyone Eventually Hates or Leaves Maven
#63Earlier quoted context omitted.
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…
The problem is that there is a large overhead associated with writing a plugin. Sometimes the things you need to do are as small as copying a file from one directory or another. Having to write a plugin to do something so small is overkill.
That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.
Re: Why Everyone Eventually Hates or Leaves Maven
#64"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…
Putting a concrete plugin version into your pom.xml helps with #1. It's solved 95% of the issues we were having with Maven.
Re: Why Everyone Eventually Hates or Leaves Maven
#65"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…
If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly.
Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable:
- submitting code to a code review site like Gerrit.
- generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily).
- integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?).
- code coverage analysis (yes, there's a Maven plugin. You ever used it?).
- FindBugs style analysis (yes, there's a Maven plugin. You ever used it?).
- interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json 1.4.2, and many other worse things.
- C code (through JNI or anything else, a perfectly reasonable thing to want to do).
- deployment.
From bitter personal experience it is possible to get so wrapped up in this that you think you have achieved something amazing when you finally finish, when it could have been done in a few hours in make or rake.
"Oh, but you can integrate it with your IDE!" The only thing your IDE actually needs to get from the Maven POM is to understand where your source code is, what you depend on and where it is, and how to run your tests. Everything else they do with command line calls, just like it was Ant.
Re: Why Everyone Eventually Hates or Leaves Maven
#66TLDR: Maven makes hard things easy and easy things really f hard.
Maven isn't even good at making hard things easy. Trivial things are easy and anything else will take a day of head scratching, minimum.
Re: Why Everyone Eventually Hates or Leaves Maven
#67I'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 once did an Ant to Maven conversion job on around 10 mature projects I didn't code. So that a large enterprise can move over to Maven and reap the productivity benefits.
Various Maven modules were restricted, including Antrun. Because the projects are old and tied to their directory structure of resources, it was more practical to script in Maven rather than follow conventions. Scripting in Maven was quite... challenging.
In this case, the problems arising from Maven also stems from the organization's context.
Re: Why Everyone Eventually Hates or Leaves Maven
#68I was surprised to see him include ant with maven. I always thought of ant as more a set of composable tools than a maven-like context, and for that reason I preferred it. That said, I recently had to use ant after many years doing Ruby, and I was surprised to find how many old annoyances were still there, like scarce/painful support for conditional execution. I wanted a task to `cp` in development and `scp/rsync` in…
Ant and a lot of the build tools that grew up around Ant don't support what make calls pattern rules very well. It's a lot like the difference between using Prolog and C to do the same task. A good example of how this is painful is to try to imagine how difficult it would be to handle the dependencies between various Java source files automatically if didn't do it for you.
To pick an SNMP related example, since I've done a bunch of that, suppose you have a MIB for your organization (using a hacked private OID that you haven't told anybody about for development, because it's easy) and then a lot of other MIBs that depend on that. And then one bright day you get your IETF approved SNMP OID for your organization, and you need to retarget your MIBs to be under that. It could be as simple as changing the base MIB to the new, official, OID and then letting your build tool rebuild the generated files in the correct dependency order--but that's hard to do with Ant. Usually you'll just rebuild all the generated files and then rebuild all the downstream code and then ... It's not trivial in make but it's not especially difficult--make for example has no real knowledge of C code, but with cc -M it doesn't need any.
Re: Why Everyone Eventually Hates or Leaves Maven
#69I think the article title is a big provocative and is drawing attention away from the main point: composable tools are better (in the long run) than contextual ones. Maven (and Ant) are contextual tools and they give a lot of benefits early on. Extending their use beyond simple things tends to become difficult and makes very messy build/deploy code.
Tools like Rake and Gradle (and Buildr) are more like thin wrappers on a turing complete language and are able to stretch and bend to fit the problem. Sure, that makes them harder to get started with, but it provides much more runway when the build gets complicated.
I've used Maven in the past on some projects and it starts off very nicely. However, without fail, I end up with some part of the build that doesn't work quite right. Or throws unresolvable errors. Or just fails, some of the time. I guess I (and everyone I've ever worked with) sucks at Maven and just can't make it work. If so, that tells me much more about Maven than my team's abilities.
P.S. I (mostly) blame XML for my Mavin chagrin. Over the years I've grown to hate XML and everything associated with it. It should burn in a fiery pit of lava. But that's just me. :)
Re: Why Everyone Eventually Hates or Leaves Maven
#70Good article. I like the idea of what Maven tries to achieve but I prefer monkeying with ant because I can get things done. If Maven or its successor ever gets to where things can't get into a mucked up state; I'm in.