16 ms·

Why Everyone Eventually Hates or Leaves Maven

207 points by dfj225 14y ago

anotherbadlogin 14y ago
Whatever "Maven" is. Nice attempt to aggrandize your post.
typicalrunt 14y ago
Oh wow. I just raged at my manager for exactly this type of problem. I'm not sure if it's due to someone's lack of technical ability, or if they get distracted by other externalities, but we always tend towards something that seems really simple at first but instead incurs a lot of technical and process debt later on. Brilliant read.
- epochwolf 14y ago
  My experience is this is caused by a lack of refactoring/ rewriting code when it can no longer support easily modification into the desired functionality.
mcherm 14y ago
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.
- jbrackett 14y ago
  You should take a look at http://www.gradle.org/ http://www.gradle.org/ if you haven't already. I worked on an ant project and decided we needed to convert to a better build system. I started down the path of Maven, but Gradle changed my mind because of the conciseness. It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post.
  - craigching 14y ago
    > It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post. The article mentions Gradle :-P Need to read the whole article ;-)
    - jbrackett 14y ago
      Hrmm that's embarrassing... well it's mentioned below the fold and everyone knows people don't pay attention to that stuff. :)
  - meddlepal 14y ago
    Gradle has given me a lot of headaches for small projects. I keep going back to it now and then and run into performance issues with it where builds that take 10 seconds in Maven take 10 min in Gradle. It's something about the dependency resolution mechanism. Something is broken, but I haven't been able to pin-point it yet. It's frustrating because I love Groovy. I write a lot of Groovy and I'd love to use a Groovy-based build tool, but I can't justify wasting a lot of time on Gradle when I know how to do what I need to do in Maven.
    - msgilligan 14y ago
      I've used Gradle on a handful of small projects and am very surprised that you're seeing an order of magnitude difference between a Maven build and a Gradle one. Can you provide a little more detail about what the script was doing for 10 minutes?
      - meddlepal 14y ago
        Last time I used it which was right around when 1.3 was released I turned on debug logging while the project built so I could see what was causing the issues. It was hanging long periods of time around a task I had to make a fat jar. If I remember correctly it was having some real trouble with locks on Ivy caches... I tried clearing out the Gradle caches and that did not resolve the problem. Since that was a small project I was able to replace the build file with a POM and assembly descriptor be done with it. If I get some more time to play around I might go back and try and collect some more info for a bug report... I have had this issue since the late Gradle betas each time I go back to using Gradle I hope the problem is resolved.
- rossjudson 14y ago
  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 go.
  - eeperson 14y ago
    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.
    - spullara 14y ago
      That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.
      - chii 14y ago
        agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter. The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your own repository server, and that comes with huge overheads. I m warming up to the idea of always mandating offline mode in maven, and then check in to the scm a preloaded repository which includes all the libs and plugins for your project, and never have to worry about external repos, or network connectivity.
        rossjudson 14y ago
        I used to be really annoyed by that too, but I'm not any more. It's _really important_ in commercial software development to understand where your code comes from. Having a local repository act as a gatekeeper does a nice job of that. It's a good idea to always have builds run where maven settings force use of a local repository. You can then easily track everything that's going into builds, and scale that up over larger numbers of projects. You can also push libraries into the repository that aren't open source, and know that you've done so. Running a maven repository doesn't take much. Sonatype's basic offerings are fine and quite effective.
- michaelt 14y ago
  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?
  - shadowmint 14y ago
    You're generating configuration files from a database as part of your build. 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.
    - lmm 14y ago
      >You basically need a test suite for your build code to make sure it's building correctly Absolutely, which is one of the best things about maven - because all your build steps are plugins written in standard Java, you can test it the same way you test your regular code.
- berlinbrown 14y ago
  I think developers are dogmatic and stick to a particular religion. I don't mind mind maven but I hate when I see an example piece of code and the only way to get it to work is complicated maven(pom) script. Then I have to spend a hour trying to figure out what is in the maven script. And you end up with only 2 or 3 jars (log4j and commons-logging junit and some other jar). Why don't you just give me the version I need in a bundled jar and I can go about my coding. My only fear with maven is when things break or someone how you have a wrong version of maven that the script requires or downloads fail or something else. If the script fails you can't do anything. And who knows, the only that was required was just compiling the java source with minimal dependencies.
  - frugalmail 14y ago
    Not sure what you're complaining about specifically, but maven has the ability to generate bundled jars when the app author includes the assembly plugin ( http://maven.apache.org/plugins/maven-assembly-plugin/ http://maven.apache.org/plugins/maven-assembly-plugin/ ). Then you would just type mvn assembly:assemble
- jamieb 14y ago
  "Because eventually your project is probably going to need it." If it has it, someone is going to think they need it. A year later you have 10,000 lines of Ant and nobody to maintain it. Building code is not hard. Discipline is hard.
ap22213 14y ago
It's a trade-off, right? As most things in software are. Recently, I inherited a project that had 10,000s of lines of ant scripts. Resource constrained, I didn't have anyone to maintain that build process. So, I took a few hours and converted those projects to several hundred lines of maven 'scripts'. Now, it works way better than the previous system, because now I can have a person focused on coding features, rather than maintaining process. Maven was what I knew at the time; and, it fit well enough. Maybe Grails is the right answer, though. Or, something else. Anyway, ultimately, it comes down to what trade-offs we make and what things we prioritize with our limited knowledge that we have available. And, that is the art of software development.
- doktrin 14y ago
  > maybe grails is the right answer The poster probably means gradle. I am not pointing this out to be pedantic, but because it's not a given that every reader will know their way around the universe of build tools.
  - ap22213 14y ago
    Oops - typo. Yeah what he said
- frugalmail 14y ago
  Gradle doesn't have the library of plugins Maven has. Do you really need stupidly concise code in a build process that gets updated .01% of the time compared to the rest of a project? I'd rather have the verbosity and formality (Maven plugin vs. customized groovy)
dasil003 14y ago
This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years. After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool. Reflecting on my history with a UNIX shell going back to the late 80s, I realized that things I had learned 10, 20 years ago from the UNIX world were still relevant today. I committed myself to getting serious about vim because I want to optimize for A) learning many programming languages and B) not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. While this kind of toolset will never provide quite the bang for the buck of a contextual IDE in a specific language, it's a phenomenal hedge against all the career risks I face in terms of Ruby becoming irrelevant, the web becoming irrelevant, Apple nerfing OS X, or any other probable sea change. No matter what happens I feel like vim + bash will bring me an immediate level of productivity in any new task I face, even if I start flattening out before I reach the Eclipse or Visual Studio level of wizardry, I don't expect any one thing to last long enough in this industry for such optimizations to pay off.
- laureny 14y ago
  > not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwdriver over a drill.
  - gizmo686 14y ago
    My understanding of dasil003's point is that it is not a complaint about IDEs, but rather about languages that are designed in such a way as to require IDEs. For example, in Java, if you want to sort a List by a given field (using the Native Collections.sort method), you would need to do something like: Collections.sort(myList, new new Comparator<E>() { public int compare(E o1, E o2) { return 01.val-02.val } } (You could also make your class implement Comparable, but then you need to own the class, have only one ordering used in the entire program, not mind making the ordering a property of the class). If you are in an IDE, then writing all that out is not to bad because of auto complete. If you are stuck in a plain-text editor, you would much prefer something like: Collections.sort(myList, lambda<E->int> x->x.val); Java 8 does incluse lambda's, so maybe this particlar case has been solved. But languages with a strong CLI pressense in the community tend to need alot less IDE than languages with a strong IDE pressense in the community.
drivebyacct2 14y ago
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.
- benjaminwootton 14y ago
  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.
  - revscat 14y ago
    It certainly isn't easy to get running if you don't use t regularly. I only have bad passing reasons to use maven, and every time it has been a huge timesink just to get it to spit out a jar file. Not a fan.
    - benjaminwootton 14y ago
      It's two lines... mvn archetype:generate mvn package
- rossjudson 14y ago
  How are you ending up with anything other than the version you specify? Dependency mismatches on versions?
  - drivebyacct2 14y ago
    More info, including an example of Maven itself shipping with mismatched versions: http://jira.codehaus.org/browse/MDEP-273 http://jira.codehaus.org/browse/MDEP-273 Depending on how bad the mismatch is and how carefully people maintain or break APIs between versions, it can introduce problems. I've not been into Java enough recently to know if this is fixed or is still affecting Maven3.
meaty 14y ago
Spot on post. Last year replaced a maven shitfest with an old fashioned Makefile which calls javac and manual dependencies. The whole port process took about 2 hours. Integration and test run time has gone from 7 minutes (to drag all the maven plugins and dependencies down) to just over two minutes. This saves us a fortune on build agent capacity as well (we use TeamCity).
- edwinnathaniel 14y ago
  You can always run maven offline.
- tonetheman 14y ago
  Exactly. I am not sure what maven people are looking at. I too have gone out of my way to not use maven. I am really good at make and reasonable at ant. If you cant build a java project with those then you are the problem not the build system.
  - brown9-2 14y ago
    The problem isn't capability, it's not wanting to deal with dozens of projects with slightly different Ant build files and commands.
- jomohke 14y ago
  It shouldn't need to download plugins and dependencies every time you build, only the first time. Had you disabled the use of a local cache?
  - jamieb 14y ago
    That's my favorite. "Maven is taking too long. It must be shit. I'll write my own!" Question: Maven is taking too long and downloading plugins and dependencies everytime. What should I do? Answer: 1. Its shit! Write my own! 2. Well, that seem suboptimal. Would the smart people who wrote it have made it download all this stuff everytime it builds? Surely that is wrong. Maybe I could google that?
  - 14y ago
lifeisstillgood 14y ago
I completely agree with the thrust of this - I see frameworks over composability everywhere these days and it makes my head spin. However we do not yet seem to plug http in the same way we pipe command lines. Something seems to be missing,
martinced 14y ago
I managed to do my entire Java career by dodging Maven but I'm now learning Clojure and I really like the language but, sadly, I'm not fluent enough in Clojure to do everything "by hand" so I'm using Leiningen... And Leiningen uses Maven under the hood :-/
- weavejester 14y ago
  Leiningen doesn't use Maven under the hood. It understands the Maven repository format, and imports a few classes from Maven for searching Maven repos, but that's pretty much it.
3amOpsGuy 14y ago
I enjoyed the article but I feel it overlooks one of the biggest reasons to use something like maven: It gives us the language to efficiently reason about and discuss build concepts with colleagues. This is a big thing, think about the most recent new starter situation you experienced, about how communication of these common build tasks was expressed. Chances are if it was with a more composable tool, the discussions were fairly detailed, the words 'just like' frequently appeared. If it was with a more rigid tool, the conversation would have been in terms that tool commonly defines.
pjungwir 14y ago
I 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 production, and I wound up having to duplicate a lot of code. Also I'd have thought that someone would have added the copy task's filter support to scp by now. (If anyone knows a clean way to do any of this, I'd love to hear it.)
- gchpaco 14y ago
  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 <javac> 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.
dustingetz 14y ago
The compromise of composabilty is that if you don't already understand the problem domain, you don't know how to structure your code. Frameworks are brilliant for paving a golden path for us to follow - we get to reuse someone elses knowledge and experience, codified into the framework. A great example is the present state of browser development t. Google "backbone sucks site:news.ycombinator.com" and you find tons of comments from people who struggle with backbone - a supercomposable library, not a framework by design. Composabilty pays off huge in the long, but you need experienced leadership to wield it. There's also a happy medium in things like Play Framework, a functional scala framework but designed almost as a collection of composable libraries so you can lean on Plays opinions for most things but since it is designed to be composable (compare to "pluggable", or "extensible") so you can swap different pieces out if you like. That is my experience, at least.
edwinnathaniel 14y ago
How about Maven 3 and Groovy DSL? http://www.mail-archive.com/users@maven.apache.org/msg126205.html http://www.mail-archive.com/users@maven.apache.org/msg126205... At least the people behind Maven took notice that there is a problem and working on something.
- monksy 14y ago
  Shhh you'll interrupt the maven hate circle jerk.. We can't have that.
huherto 14y ago
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 https://github.com/huherto/jashi
- _pdeschen 14y ago
  Hum? Groovy?
achacha 14y ago
Ivy and Maven repository without the insanity of the POM files... it works and stays out of your way.
tomlu 14y ago
I've worked on two build systems (and used many more). The conclusion I have arrived at is you don't want a declarative-only system (like Ant). They can be convenient but as your needs grow more complex they start becoming a hindrance. 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.
hakaaaaak 14y ago
It's not Maven. It's Java and XML. They both end up involving much more overhead than Ruby/Rake.
- huherto 14y ago
  IMHO, it is XML.
  - frugalmail 14y ago
    XML is a great language since it has the power of schemas and DTDs. It makes it easy to validate the data you expect in each of the fields. And fuck am I tired of hearing about how saving 10% of your keystrokes during authorship is such a great thing. Most of the time spent on software in in maintenance, so you want better readability than terseness. coffeescript, yaml, etc... are far inferior solutions for most of the uses they get put towards.
    - lmm 14y ago
      >XML is a great language since it has the power of schemas and DTDs. It makes it easy to validate the data you expect in each of the fields. Quite the opposite. XML Schema is an awful mess - it's not even representable in XML; it's not a good language for expressing validation constraints, it's neither simple enough to be easy, nor powerful enough to express all your requirements. And the need to support schema leads to DTDs and namespaces, which are responsible for most of the screwups of using XML in the real world. If XML were just tags, parsers didn't try to connect to the internet to validate everything, and tools didn't bother with namespaces, it would be usable enough that we probably wouldn't have needed to invent JSON.
- frugalmail 14y ago
  You get something in exchange to that overhead: 1) predictability 2) static analysis 3) quality (static typeing vs. duck typing) 4) sophistication/maturity 5) reproducabilty 6) tooling All that's not always necessary, but if you know the thing you're building has a shelf life of at least 2 years then ruby/rake are pretty shitty tools.
mathattack 14y ago
I love the Access analogy. It burned me quite a few times in prior lives, when every project started with, "Let's build an access database." Ultimately it's a tradeoff in abstraction and usability.
- chii 14y ago
  i actually doubt the problems with access are really that bad - sure you outgrow it eventually, but you'd be surprised at what its capable of. Often the real underlying cause is that a business owner with little to no programming knowledge makes something which works ok, but is architectually wrong. For example, bad table structure/relationships. Or after a while, they want to 'put their app online', and asks a poor intern to convert it.
  - mathattack 14y ago
    This is true too. Sometimes screens are designed by people who don't think in terms of relational tables, and then the data eventually gets messed up.
deleted 14y ago
[deleted]
vorg 14y ago
What are the biggest differences between Rake, Gradle, and Leiningen? All 3 allow their respective language (i.e. Ruby, Groovy, Clojure) to be used within the build script, but besides the pros/cons and popularity of those languages, what are the differences between the build tools themselves?
Niten 14y ago
> Donald Knuth was asked to write a program to solve this text handling problem: read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies. He wrote a program consisting of more than ten pages of Pascal, designing (and documenting) a new algorithm along the way. Then, Doug McIlroy demonstrated a shell script that would easily fit within a Twitter post that solved the problem more simply, elegantly, and understandably (if you understand shell commands) Fine anecdote, but anyone want to take a wager as to the relative time and space complexity of the two solutions? I imagine this is sort of comparing apples and oranges.
- nisa 14y ago
  I guess it is part of the idea that you can ignore that. The shell script is _good enough_ for 80% (I made this up) of use cases. Knuth's solution is probably faster and requires less resources but if I want to reverse the filter order or change something else You are way faster using the shell script. It's also probably not so difficult to look up how each of these tools work internally to make an informed guess on time and space complexity. This will come in handy if you use the tools next time. And unix tools aren't so slow. I wrote some C++ code using mmap() files to filter out some chars. It was only marginally faster than some pipe using tr.
  - Niten 14y ago
    To be more precise, I think the biggest problem with this anecdote is the notion that this guy somehow "one-upped" Knuth by coming up with a pragmatic rather than a theroetically optimal solution. Knuth is a mathematician after all, and if someone asks him to write a program they're implicitly asking for a mathematical result, not an unremarkable engineering tool. So no, taking this anecdote at face value, this guy didn't "one-up" Knuth; they were effectively answering two different questions. There is more to computer science than finding the simplest shell script to solve the 80% case.
6ren 14y ago
I now use bash instead of ant. It's really fast, makes sense, does whatever I want. But it has the lisp problem (and now ruby problem) of everyone making their own tooling, without standardisation. (where a "standard" is procrustean: it doesn't exactly fit any situation, but the situation is forced to fit it). Pre-chasm innovators/early-adopters love it; everyone else hates it. BTW: I don't think "contextual" is a very descriptive term ("composable" is great though)
rjzzleep 14y ago
i'm really wondering, why xml is burried so deep down in the comments. I would argue that Maven is just reflecting a methodology implied by xml, some like it, but well... this: http://www.defmacro.org/ramblings/lisp.html http://www.defmacro.org/ramblings/lisp.html even though having completely different intentions, shows the parallels quite well, imho
- andrewflnr 14y ago
  I think most of it is verbosity, both that inherent in XML and extra caused by crummy schemas, that makes people hate XML. It turned into an "enterprise" thing, with all the philosophy that entails.
amalag 14y ago
I can't understand the Maven hate. People prefer their own half baked ant tasks which don't handle dependencies? IMHO Maven takes some getting used to, but it brings a lot to the table and can make the build process very repeatable and extensible.
andrewem 14y ago
Doug McIlroy's solution is genius, and I hesitate to try to improve it, but it seems to me that if you reverse the order of the 'tr' commands, then you can slightly simplify the one that turns non-word characters into newlines, like so: tr A-Z a-z | tr -cs a-z '\n' | ... Since you first turn upper-case characters into lower-case ones, you then get to replace only things that aren't in a-z with newlines, rather than things that aren't in A-Za-z. It saves a whopping three characters!
berlinbrown 14y ago
If you look at the practical real-world environments, Maven beats out most other approaches for large projects. I think you have three or four different build setups. I prefer Maven for large projects and Ant for small projects. Up votes for the person that makes working, maintainable, easy to read and modify maven scripts. (not you Spring or JBoss). Anyway, you have three levels of builds. - Complex Perl scripts, bash/unix scripts : these people are insane and generally have degrees in physics and mathematics. They write scripts that are unreadable, can't modify, are cryptic and I imagine that that the authors can't read them. I sometimes see these in old Linux programs. - Complex Make, Autoconf, bash/unix scripts : A little better than the perl build scripts but still a complex because you have to understand each command used. I am not fan and never was a C/C++ developer. I guess these are still used in the non-Java world. I am looking at you 'OpenJDK/Sun JDK' - Complex Ant scripts : These aren't bad, easy read, a little bit difficult to maintain over time. I think most developers prefer Maven but don't mind an Ant script if the project is small - Maven Scripts : I think people use maven because not much else exists. And the problem of compiling code is not that serious as the actual application development.
- chrismaeda 14y ago
  I've had the opposite experience. I've converted 2-3 complex build systems implemented in different flavors of make to ant. It's tedious but it's doable. And once you get to ant, it's a lot easier to maintain compared to make. I looked at maven a couple time but could never figure out how to convert a make-based build to maven because there is always a bunch of weird hacks lurking in the makefile. However, I do see how maven would be fine for a new project.
  - cbsmith 14y ago
    Honestly, make based projects are generally infinitely easier to parse and manipulate than Maven. Maven helps by providing a fixed organizational structure that is immediately familiar (and this is the advantage of being opinionated that I do think the article understates), but you can keep the structure and use make and be much better for it.
laureny 14y ago
It's hard to be wrong when you claim that you either eventually hate or stop using a software tool. I can't think of many tools that escape this simple truth.
- lmm 14y ago
  Ironically enough Maven is quite possibly the only exception in my own experience.
jamieb 14y ago
"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 do it. You may think you need to do it, you probably don't. Maybe what you need is a more powerful deployment system, or something that takes over after your java/scala/whatever is built. If you're building perl, C, C++, sure, maven isn't going to do it for you. If you're building java, you're sorted. My favorite is when this sequence happens (I have seen it first hand): 1. Maven is this external system that we have no control over. 2. We will write our own system that will be awesome. 3. Wow, look, every project uses our Build System! 4. Oh, look, someone on project X changed B.S. and now Projects A-N don't work! 5. We will lock down B.S. so only the one person who wrote it can change it! 6. ... 7. B.S. is this internal system that we have no control over! 8. ... 9. Can we add support for merging war files? 10. No that'll take weeks, and Bob isn't available anyway. I'm sure you can fuck that up just as well using Ruby. Go for it. I work in a java shop currently. There's got to be a hundred of us. Every single one uses an IDE. When I use maven, my IDE just works. eclipse, intellij, netbeans all support maven. Want to put a bunch of files in a common war to share? maven has a merge-war plugin and intellij and eclipse know what it means: they both build projects that copy the files just like maven would do. Better yet, as you edit those files, no matter where they are, both eclipse and intellij update the files in the deploy target and they are available when you refresh your browser. There is a huge amount of investment in making this stuff work. This is convention over configuration. No tool can do this with Ant (or Ruby) unless it runs the Ant and the Ruby, and then you've side stepped the IDE and reduced them to dumb text editors. With an Ant project, the IDE can't know that when I edit file A, it is transmogrified into file Z. (If it could, it could solve the halting problem). With Maven, the IDE implements convention, and so it know that File A is compiled to File B and then must be copied to location Z because its part of a merged war. Add JRebel to the equation and pretty much any change to the code is immediately runnable. Its dangerously easy to spike away instead of writing tests!
- spullara 14y ago
  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.
moneypenny 14y ago
TLDR: Maven makes hard things easy and easy things really f hard.
- gchpaco 14y ago
  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.
  - chii 14y ago
    what would you consider something as trivial, and what is hard?
    - gchpaco 14y ago
      Building java libraries isn't really all that difficult. Not is packaging them. Damned if it doesn't take 30 lines of XML to do it in maven, but these kinds of see-spot-run situations are pretty easy. Extremely difficult in maven and five minutes work in make or ant is things like "running LaTeX to generate a PDF of some of your documentation, because it is math laden and HTML isn't suitable". This is not theoretical; I had to do this at the place that was using maven and we depended on some semi-obscure mathematical formalisms like the stable distribution. Intermediate between these two is driving things with maven plugins, which is either easy (because you're doing something trivial) or fiendishly difficult because the debugging output is terrible, the docs are worse and the only thing left to you is to Use The Source, Luke. Every nontrivial maven plugin I've ever used has tripped this at some point, be it loading config files, including the dependencies, or something else.
      - rossjudson 14y ago
        Or you could use org.codehaus.mojo:latex-maven-plugin, stick your latex and graphics in src/main/latex/<doc>, and watch it 'just work', like I do. I agree that not every maven plugin does exactly what you want it to, but a lot of them get pretty damn close, and as the authors iterate them, they gain a lot of flexibility.
tomohawk 14y ago
I've found buildr (http://buildr.apache.org http://buildr.apache.org) to be a great replacement for maven. It provides many of the capabilities that maven does, but it's also got all of the power of ruby/rake for taking care of those things that come up that the plugin/declarative approach just cannot handle reasonably. We converted our maven builds in a day and never looked back.
politician 14y ago
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.
Corrado 14y ago
I 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. :)
jebblue 14y ago
Good 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.
- frugalmail 14y ago
  strange, by default maven is much more strict about things, so it's hard to muck up. Perhaps you weren't creating the maven project in the format it wants you to create it in (which IMO, is a good one). Have you tried creating new projects with mvn archetype:generate ?
  - jebblue 14y ago
    >> Generates a new project from an archetype, or updated the actual project if using a partial archetype. If the project is fully generated, it is generated in a directory corresponding to its artifactId. If the project is updated with a partial archetype, it is done in the current directory. I don't recall trying that however, sorry that whole description from the link you provided, it just doesn't make sense to me. In general, when I try to use Maven, Eclipse ends up complaining. Then I fix it so Eclipse is happy then Maven complains. Maybe the answer for me would really just be get the Maven and the Eclipse people to agree on how to create and manage projects with the Eclipse wizards.
wellpast 14y ago
I wholeheartedly disagree with this post, though I do like his conceptual framework of composable and contextual abstractions. I've worked on countless Maven builds and have done everything under the sun. Maven's plugin system allows you to ultimately achieve whatever you need out of your build--in the 10% case that you have a need that isn't already covered by the varied plethora of plugins out there. You can even call out to Ant using the antrun plugin. I've found so much simplicity, reliability, continued payoff in my use of Maven. I've heard complaints but usually from people that refuse to understand how it functions declaratively. Declarative systems like Maven ask that you learn something first, and then reward you infinitely if you do; imperative systems let you do something immediately without learning a model, but then make you infinitely pay for it.
- frugalmail 14y ago
  brilliant summary.
Uchikoma 14y ago
Maven just works and if you stay within it's intent, it does it's job. We use Maven with Bamboo for continuous integration and it just works. We play with the idea to move to Gradle b/c it's more powerful, but the effort is non trivial and the real benefits - beside the 'but it's programmable' - not clear.
- lmm 14y ago
  "It's programmable" is a downside here. You do not want your build system to be turing-complete; keep it simple, and Maven enforces that.
Uchikoma 14y ago
After 3 years of SBT for Scala development, which plainly does not work, b/c SBT developers do not like simplicity (the irony!) and are more interested in doing cool stuff than stuff that works, I'm only a small push away from going back to Maven/Zinc, that favors 'just works and you can't shoot yourself in the knee with an arrow' over 'powerful'.
- lmm 14y ago
  Do it. I've been building Scala with maven for years; it just works.
sabalaba 14y ago
The author didn't provide any background about the original Knuth "Literate Programming" paper and subsequent review by McIllroy. Knuth was using that code to demonstrate Literate Programming style. While the quote / anecdote was taken a bit out of context, I agree with the fundamental idea: code reuse. [1] http://en.wikipedia.org/wiki/Literate_programming http://en.wikipedia.org/wiki/Literate_programming [2] "Literate Programming" http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf
NeillAlexander 14y ago
"Once you start fighting with Maven, it’ll never return to the rosy days when your relationship was young." The key is, you don't start fighting with Maven. "The philosophy of Tai Chi Chuan is that if one uses hardness to resist violent force, then both sides are certain to be injured at least to some degree. Such injury, according to tai chi theory, is a natural consequence of meeting brute force with brute force. Instead, students are taught not to directly fight or resist an incoming force, but to meet it in softness and follow its motion while remaining in physical contact until the incoming force of attack exhausts itself or can be safely redirected, meeting yang with yin." (http:// http:// en.wikipedia.org/wiki/Tai_chi_chuan) If you fight with Maven, you will lose. If you meet it in softness and follow its motion you will attain build enlightenment...
traxtech 14y ago
Imho Maven, despite its wide range of plugins and extentions mechanisms, is quite "convention over configuration" (cought cought) and really is made for projects that can adapt to its conventions, and to the popular Java artifacts layouts. The problem is, when it does not suits you, the competition is not really well known. Gradle maybe ?
deltasquared 14y ago
For me personally, leinigin is why I don't use Maven that much ^_- Also, you would be surprised just how much "Java" programming you can do with a decent XML editor. IDE's are overrated.
nichols 14y ago
better link: http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html http://kent.spillner.org/blog/work/2009/11/14/java-build-too... After about a year of experience with Maven, I find that: * The "surefire" plugin is named ironically. The build often fails without a message about what unit test failed. * Maven is extremely slow. Eclipse builds the source in 30 seconds max; Maven takes 5 minutes. * Maven's output is extremely verbose, but if anything goes wrong, it "helpfully" tells you to rerun it with -X -e to get the actual error message and stack trace. You can run it with -X -e all the time if you want, but I think it generates so much output that it actually slows down the build. Yes, really. * There are a lot of things you just CANNOT DO in Maven. One example is bundling a Maven plugin together with the rest of your Maven source and use that same plugin elsewhere in the project. It fails during the early phases of the default lifecycle because the plugin isn't installed yet. But only by getting to the later phases of the lifecycle can you install the plugin. But you can't do that because the early phases fail. An infinite cycle of despair is right. * Even the most trivial project takes a few screenfuls of XML to set up in Maven. * Maven's dependency management is poor, too. If you have some library A that pulls in B, and another library C that pulls in a slightly different version of B, you can get misbuilds. It's your job to identify and fix these problems. They will show up at runtime. And let's not even talk about SNAPSHOT and how horribly that can go wrong. * Maven is also known for pulling in tons of unnecessary dependencies. But hey, you don't mind 50 more megabytes of jars on your CLASSPATH, do you? I was honestly expecting the article to address some of these points, instead of vague philosophical ramblings. Seriously, Maven is horrible. This article gives you no inkling of just how bad it is.
commentator 14y ago
I like this one: What has Maven ever done for us? http://www.wakaleo.com/blog/what-has-maven-ever-done-for-us http://www.wakaleo.com/blog/what-has-maven-ever-done-for-us :-)

207 points by dfj225 14y ago

Whatever "Maven" is. Nice attempt to aggrandize your post.

Oh wow. I just raged at my manager for exactly this type of problem. I'm not sure if it's due to someone's lack of technical ability, or if they get distracted by other externalities, but we always tend towards something that seems really simple at first but instead incurs a lot of technical and process debt later on. Brilliant read.

epochwolf 14y ago
My experience is this is caused by a lack of refactoring/ rewriting code when it can no longer support easily modification into the desired functionality.

mcherm 14y ago

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.

jbrackett 14y ago
You should take a look at http://www.gradle.org/ http://www.gradle.org/ if you haven't already. I worked on an ant project and decided we needed to convert to a better build system. I started down the path of Maven, but Gradle changed my mind because of the conciseness. It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post.
- craigching 14y ago
  > It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post. The article mentions Gradle :-P Need to read the whole article ;-)
  - jbrackett 14y ago
    Hrmm that's embarrassing... well it's mentioned below the fold and everyone knows people don't pay attention to that stuff. :)
- meddlepal 14y ago
  Gradle has given me a lot of headaches for small projects. I keep going back to it now and then and run into performance issues with it where builds that take 10 seconds in Maven take 10 min in Gradle. It's something about the dependency resolution mechanism. Something is broken, but I haven't been able to pin-point it yet. It's frustrating because I love Groovy. I write a lot of Groovy and I'd love to use a Groovy-based build tool, but I can't justify wasting a lot of time on Gradle when I know how to do what I need to do in Maven.
  - msgilligan 14y ago
    I've used Gradle on a handful of small projects and am very surprised that you're seeing an order of magnitude difference between a Maven build and a Gradle one. Can you provide a little more detail about what the script was doing for 10 minutes?
    - meddlepal 14y ago
      Last time I used it which was right around when 1.3 was released I turned on debug logging while the project built so I could see what was causing the issues. It was hanging long periods of time around a task I had to make a fat jar. If I remember correctly it was having some real trouble with locks on Ivy caches... I tried clearing out the Gradle caches and that did not resolve the problem. Since that was a small project I was able to replace the build file with a POM and assembly descriptor be done with it. If I get some more time to play around I might go back and try and collect some more info for a bug report... I have had this issue since the late Gradle betas each time I go back to using Gradle I hope the problem is resolved.
rossjudson 14y ago
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 go.
- eeperson 14y ago
  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.
  - spullara 14y ago
    That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.
    - chii 14y ago
      agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter. The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your own repository server, and that comes with huge overheads. I m warming up to the idea of always mandating offline mode in maven, and then check in to the scm a preloaded repository which includes all the libs and plugins for your project, and never have to worry about external repos, or network connectivity.
      - rossjudson 14y ago
        I used to be really annoyed by that too, but I'm not any more. It's _really important_ in commercial software development to understand where your code comes from. Having a local repository act as a gatekeeper does a nice job of that. It's a good idea to always have builds run where maven settings force use of a local repository. You can then easily track everything that's going into builds, and scale that up over larger numbers of projects. You can also push libraries into the repository that aren't open source, and know that you've done so. Running a maven repository doesn't take much. Sonatype's basic offerings are fine and quite effective.
michaelt 14y ago
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?
- shadowmint 14y ago
  You're generating configuration files from a database as part of your build. 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.
  - lmm 14y ago
    >You basically need a test suite for your build code to make sure it's building correctly Absolutely, which is one of the best things about maven - because all your build steps are plugins written in standard Java, you can test it the same way you test your regular code.
berlinbrown 14y ago
I think developers are dogmatic and stick to a particular religion. I don't mind mind maven but I hate when I see an example piece of code and the only way to get it to work is complicated maven(pom) script. Then I have to spend a hour trying to figure out what is in the maven script. And you end up with only 2 or 3 jars (log4j and commons-logging junit and some other jar). Why don't you just give me the version I need in a bundled jar and I can go about my coding. My only fear with maven is when things break or someone how you have a wrong version of maven that the script requires or downloads fail or something else. If the script fails you can't do anything. And who knows, the only that was required was just compiling the java source with minimal dependencies.
- frugalmail 14y ago
  Not sure what you're complaining about specifically, but maven has the ability to generate bundled jars when the app author includes the assembly plugin ( http://maven.apache.org/plugins/maven-assembly-plugin/ http://maven.apache.org/plugins/maven-assembly-plugin/ ). Then you would just type mvn assembly:assemble
jamieb 14y ago
"Because eventually your project is probably going to need it." If it has it, someone is going to think they need it. A year later you have 10,000 lines of Ant and nobody to maintain it. Building code is not hard. Discipline is hard.

ap22213 14y ago

It's a trade-off, right? As most things in software are. Recently, I inherited a project that had 10,000s of lines of ant scripts. Resource constrained, I didn't have anyone to maintain that build process. So, I took a few hours and converted those projects to several hundred lines of maven 'scripts'. Now, it works way better than the previous system, because now I can have a person focused on coding features, rather than maintaining process. Maven was what I knew at the time; and, it fit well enough. Maybe Grails is the right answer, though. Or, something else. Anyway, ultimately, it comes down to what trade-offs we make and what things we prioritize with our limited knowledge that we have available. And, that is the art of software development.

doktrin 14y ago
> maybe grails is the right answer The poster probably means gradle. I am not pointing this out to be pedantic, but because it's not a given that every reader will know their way around the universe of build tools.
- ap22213 14y ago
  Oops - typo. Yeah what he said
frugalmail 14y ago
Gradle doesn't have the library of plugins Maven has. Do you really need stupidly concise code in a build process that gets updated .01% of the time compared to the rest of a project? I'd rather have the verbosity and formality (Maven plugin vs. customized groovy)

dasil003 14y ago

This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years. After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool. Reflecting on my history with a UNIX shell going back to the late 80s, I realized that things I had learned 10, 20 years ago from the UNIX world were still relevant today. I committed myself to getting serious about vim because I want to optimize for A) learning many programming languages and B) not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. While this kind of toolset will never provide quite the bang for the buck of a contextual IDE in a specific language, it's a phenomenal hedge against all the career risks I face in terms of Ruby becoming irrelevant, the web becoming irrelevant, Apple nerfing OS X, or any other probable sea change. No matter what happens I feel like vim + bash will bring me an immediate level of productivity in any new task I face, even if I start flattening out before I reach the Eclipse or Visual Studio level of wizardry, I don't expect any one thing to last long enough in this industry for such optimizations to pay off.

laureny 14y ago
> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwdriver over a drill.
- gizmo686 14y ago
  My understanding of dasil003's point is that it is not a complaint about IDEs, but rather about languages that are designed in such a way as to require IDEs. For example, in Java, if you want to sort a List by a given field (using the Native Collections.sort method), you would need to do something like: Collections.sort(myList, new new Comparator<E>() { public int compare(E o1, E o2) { return 01.val-02.val } } (You could also make your class implement Comparable, but then you need to own the class, have only one ordering used in the entire program, not mind making the ordering a property of the class). If you are in an IDE, then writing all that out is not to bad because of auto complete. If you are stuck in a plain-text editor, you would much prefer something like: Collections.sort(myList, lambda<E->int> x->x.val); Java 8 does incluse lambda's, so maybe this particlar case has been solved. But languages with a strong CLI pressense in the community tend to need alot less IDE than languages with a strong IDE pressense in the community.

drivebyacct2 14y ago

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.

benjaminwootton 14y ago
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.
- revscat 14y ago
  It certainly isn't easy to get running if you don't use t regularly. I only have bad passing reasons to use maven, and every time it has been a huge timesink just to get it to spit out a jar file. Not a fan.
  - benjaminwootton 14y ago
    It's two lines... mvn archetype:generate mvn package
rossjudson 14y ago
How are you ending up with anything other than the version you specify? Dependency mismatches on versions?
- drivebyacct2 14y ago
  More info, including an example of Maven itself shipping with mismatched versions: http://jira.codehaus.org/browse/MDEP-273 http://jira.codehaus.org/browse/MDEP-273 Depending on how bad the mismatch is and how carefully people maintain or break APIs between versions, it can introduce problems. I've not been into Java enough recently to know if this is fixed or is still affecting Maven3.

meaty 14y ago

Spot on post. Last year replaced a maven shitfest with an old fashioned Makefile which calls javac and manual dependencies. The whole port process took about 2 hours. Integration and test run time has gone from 7 minutes (to drag all the maven plugins and dependencies down) to just over two minutes. This saves us a fortune on build agent capacity as well (we use TeamCity).

edwinnathaniel 14y ago
You can always run maven offline.
tonetheman 14y ago
Exactly. I am not sure what maven people are looking at. I too have gone out of my way to not use maven. I am really good at make and reasonable at ant. If you cant build a java project with those then you are the problem not the build system.
- brown9-2 14y ago
  The problem isn't capability, it's not wanting to deal with dozens of projects with slightly different Ant build files and commands.
jomohke 14y ago
It shouldn't need to download plugins and dependencies every time you build, only the first time. Had you disabled the use of a local cache?
- jamieb 14y ago
  That's my favorite. "Maven is taking too long. It must be shit. I'll write my own!" Question: Maven is taking too long and downloading plugins and dependencies everytime. What should I do? Answer: 1. Its shit! Write my own! 2. Well, that seem suboptimal. Would the smart people who wrote it have made it download all this stuff everytime it builds? Surely that is wrong. Maybe I could google that?
- 14y ago

lifeisstillgood 14y ago

I completely agree with the thrust of this - I see frameworks over composability everywhere these days and it makes my head spin. However we do not yet seem to plug http in the same way we pipe command lines. Something seems to be missing,

martinced 14y ago

I managed to do my entire Java career by dodging Maven but I'm now learning Clojure and I really like the language but, sadly, I'm not fluent enough in Clojure to do everything "by hand" so I'm using Leiningen... And Leiningen uses Maven under the hood :-/

weavejester 14y ago
Leiningen doesn't use Maven under the hood. It understands the Maven repository format, and imports a few classes from Maven for searching Maven repos, but that's pretty much it.

3amOpsGuy 14y ago

I enjoyed the article but I feel it overlooks one of the biggest reasons to use something like maven: It gives us the language to efficiently reason about and discuss build concepts with colleagues. This is a big thing, think about the most recent new starter situation you experienced, about how communication of these common build tasks was expressed. Chances are if it was with a more composable tool, the discussions were fairly detailed, the words 'just like' frequently appeared. If it was with a more rigid tool, the conversation would have been in terms that tool commonly defines.

pjungwir 14y ago

I 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 production, and I wound up having to duplicate a lot of code. Also I'd have thought that someone would have added the copy task's filter support to scp by now. (If anyone knows a clean way to do any of this, I'd love to hear it.)

gchpaco 14y ago
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 <javac> 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.

dustingetz 14y ago

The compromise of composabilty is that if you don't already understand the problem domain, you don't know how to structure your code. Frameworks are brilliant for paving a golden path for us to follow - we get to reuse someone elses knowledge and experience, codified into the framework. A great example is the present state of browser development t. Google "backbone sucks site:news.ycombinator.com" and you find tons of comments from people who struggle with backbone - a supercomposable library, not a framework by design. Composabilty pays off huge in the long, but you need experienced leadership to wield it. There's also a happy medium in things like Play Framework, a functional scala framework but designed almost as a collection of composable libraries so you can lean on Plays opinions for most things but since it is designed to be composable (compare to "pluggable", or "extensible") so you can swap different pieces out if you like. That is my experience, at least.

edwinnathaniel 14y ago

How about Maven 3 and Groovy DSL? http://www.mail-archive.com/users@maven.apache.org/msg126205.html http://www.mail-archive.com/users@maven.apache.org/msg126205... At least the people behind Maven took notice that there is a problem and working on something.

monksy 14y ago
Shhh you'll interrupt the maven hate circle jerk.. We can't have that.

huherto 14y ago

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 https://github.com/huherto/jashi

_pdeschen 14y ago
Hum? Groovy?

achacha 14y ago

Ivy and Maven repository without the insanity of the POM files... it works and stays out of your way.

tomlu 14y ago

I've worked on two build systems (and used many more). The conclusion I have arrived at is you don't want a declarative-only system (like Ant). They can be convenient but as your needs grow more complex they start becoming a hindrance. 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.

hakaaaaak 14y ago

It's not Maven. It's Java and XML. They both end up involving much more overhead than Ruby/Rake.

huherto 14y ago
IMHO, it is XML.
- frugalmail 14y ago
  XML is a great language since it has the power of schemas and DTDs. It makes it easy to validate the data you expect in each of the fields. And fuck am I tired of hearing about how saving 10% of your keystrokes during authorship is such a great thing. Most of the time spent on software in in maintenance, so you want better readability than terseness. coffeescript, yaml, etc... are far inferior solutions for most of the uses they get put towards.
  - lmm 14y ago
    >XML is a great language since it has the power of schemas and DTDs. It makes it easy to validate the data you expect in each of the fields. Quite the opposite. XML Schema is an awful mess - it's not even representable in XML; it's not a good language for expressing validation constraints, it's neither simple enough to be easy, nor powerful enough to express all your requirements. And the need to support schema leads to DTDs and namespaces, which are responsible for most of the screwups of using XML in the real world. If XML were just tags, parsers didn't try to connect to the internet to validate everything, and tools didn't bother with namespaces, it would be usable enough that we probably wouldn't have needed to invent JSON.
frugalmail 14y ago
You get something in exchange to that overhead: 1) predictability 2) static analysis 3) quality (static typeing vs. duck typing) 4) sophistication/maturity 5) reproducabilty 6) tooling All that's not always necessary, but if you know the thing you're building has a shelf life of at least 2 years then ruby/rake are pretty shitty tools.

mathattack 14y ago

I love the Access analogy. It burned me quite a few times in prior lives, when every project started with, "Let's build an access database." Ultimately it's a tradeoff in abstraction and usability.

chii 14y ago
i actually doubt the problems with access are really that bad - sure you outgrow it eventually, but you'd be surprised at what its capable of. Often the real underlying cause is that a business owner with little to no programming knowledge makes something which works ok, but is architectually wrong. For example, bad table structure/relationships. Or after a while, they want to 'put their app online', and asks a poor intern to convert it.
- mathattack 14y ago
  This is true too. Sometimes screens are designed by people who don't think in terms of relational tables, and then the data eventually gets messed up.

deleted 14y ago

[deleted]

vorg 14y ago

What are the biggest differences between Rake, Gradle, and Leiningen? All 3 allow their respective language (i.e. Ruby, Groovy, Clojure) to be used within the build script, but besides the pros/cons and popularity of those languages, what are the differences between the build tools themselves?

Niten 14y ago

> Donald Knuth was asked to write a program to solve this text handling problem: read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies. He wrote a program consisting of more than ten pages of Pascal, designing (and documenting) a new algorithm along the way. Then, Doug McIlroy demonstrated a shell script that would easily fit within a Twitter post that solved the problem more simply, elegantly, and understandably (if you understand shell commands) Fine anecdote, but anyone want to take a wager as to the relative time and space complexity of the two solutions? I imagine this is sort of comparing apples and oranges.

nisa 14y ago
I guess it is part of the idea that you can ignore that. The shell script is _good enough_ for 80% (I made this up) of use cases. Knuth's solution is probably faster and requires less resources but if I want to reverse the filter order or change something else You are way faster using the shell script. It's also probably not so difficult to look up how each of these tools work internally to make an informed guess on time and space complexity. This will come in handy if you use the tools next time. And unix tools aren't so slow. I wrote some C++ code using mmap() files to filter out some chars. It was only marginally faster than some pipe using tr.
- Niten 14y ago
  To be more precise, I think the biggest problem with this anecdote is the notion that this guy somehow "one-upped" Knuth by coming up with a pragmatic rather than a theroetically optimal solution. Knuth is a mathematician after all, and if someone asks him to write a program they're implicitly asking for a mathematical result, not an unremarkable engineering tool. So no, taking this anecdote at face value, this guy didn't "one-up" Knuth; they were effectively answering two different questions. There is more to computer science than finding the simplest shell script to solve the 80% case.

6ren 14y ago

I now use bash instead of ant. It's really fast, makes sense, does whatever I want. But it has the lisp problem (and now ruby problem) of everyone making their own tooling, without standardisation. (where a "standard" is procrustean: it doesn't exactly fit any situation, but the situation is forced to fit it). Pre-chasm innovators/early-adopters love it; everyone else hates it. BTW: I don't think "contextual" is a very descriptive term ("composable" is great though)

rjzzleep 14y ago

i'm really wondering, why xml is burried so deep down in the comments. I would argue that Maven is just reflecting a methodology implied by xml, some like it, but well... this: http://www.defmacro.org/ramblings/lisp.html http://www.defmacro.org/ramblings/lisp.html even though having completely different intentions, shows the parallels quite well, imho

andrewflnr 14y ago
I think most of it is verbosity, both that inherent in XML and extra caused by crummy schemas, that makes people hate XML. It turned into an "enterprise" thing, with all the philosophy that entails.

amalag 14y ago

I can't understand the Maven hate. People prefer their own half baked ant tasks which don't handle dependencies? IMHO Maven takes some getting used to, but it brings a lot to the table and can make the build process very repeatable and extensible.

andrewem 14y ago

Doug McIlroy's solution is genius, and I hesitate to try to improve it, but it seems to me that if you reverse the order of the 'tr' commands, then you can slightly simplify the one that turns non-word characters into newlines, like so: tr A-Z a-z | tr -cs a-z '\n' | ... Since you first turn upper-case characters into lower-case ones, you then get to replace only things that aren't in a-z with newlines, rather than things that aren't in A-Za-z. It saves a whopping three characters!

berlinbrown 14y ago

If you look at the practical real-world environments, Maven beats out most other approaches for large projects. I think you have three or four different build setups. I prefer Maven for large projects and Ant for small projects. Up votes for the person that makes working, maintainable, easy to read and modify maven scripts. (not you Spring or JBoss). Anyway, you have three levels of builds. - Complex Perl scripts, bash/unix scripts : these people are insane and generally have degrees in physics and mathematics. They write scripts that are unreadable, can't modify, are cryptic and I imagine that that the authors can't read them. I sometimes see these in old Linux programs. - Complex Make, Autoconf, bash/unix scripts : A little better than the perl build scripts but still a complex because you have to understand each command used. I am not fan and never was a C/C++ developer. I guess these are still used in the non-Java world. I am looking at you 'OpenJDK/Sun JDK' - Complex Ant scripts : These aren't bad, easy read, a little bit difficult to maintain over time. I think most developers prefer Maven but don't mind an Ant script if the project is small - Maven Scripts : I think people use maven because not much else exists. And the problem of compiling code is not that serious as the actual application development.

chrismaeda 14y ago
I've had the opposite experience. I've converted 2-3 complex build systems implemented in different flavors of make to ant. It's tedious but it's doable. And once you get to ant, it's a lot easier to maintain compared to make. I looked at maven a couple time but could never figure out how to convert a make-based build to maven because there is always a bunch of weird hacks lurking in the makefile. However, I do see how maven would be fine for a new project.
- cbsmith 14y ago
  Honestly, make based projects are generally infinitely easier to parse and manipulate than Maven. Maven helps by providing a fixed organizational structure that is immediately familiar (and this is the advantage of being opinionated that I do think the article understates), but you can keep the structure and use make and be much better for it.

laureny 14y ago

It's hard to be wrong when you claim that you either eventually hate or stop using a software tool. I can't think of many tools that escape this simple truth.

lmm 14y ago
Ironically enough Maven is quite possibly the only exception in my own experience.

jamieb 14y ago

"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 do it. You may think you need to do it, you probably don't. Maybe what you need is a more powerful deployment system, or something that takes over after your java/scala/whatever is built. If you're building perl, C, C++, sure, maven isn't going to do it for you. If you're building java, you're sorted. My favorite is when this sequence happens (I have seen it first hand): 1. Maven is this external system that we have no control over. 2. We will write our own system that will be awesome. 3. Wow, look, every project uses our Build System! 4. Oh, look, someone on project X changed B.S. and now Projects A-N don't work! 5. We will lock down B.S. so only the one person who wrote it can change it! 6. ... 7. B.S. is this internal system that we have no control over! 8. ... 9. Can we add support for merging war files? 10. No that'll take weeks, and Bob isn't available anyway. I'm sure you can fuck that up just as well using Ruby. Go for it. I work in a java shop currently. There's got to be a hundred of us. Every single one uses an IDE. When I use maven, my IDE just works. eclipse, intellij, netbeans all support maven. Want to put a bunch of files in a common war to share? maven has a merge-war plugin and intellij and eclipse know what it means: they both build projects that copy the files just like maven would do. Better yet, as you edit those files, no matter where they are, both eclipse and intellij update the files in the deploy target and they are available when you refresh your browser. There is a huge amount of investment in making this stuff work. This is convention over configuration. No tool can do this with Ant (or Ruby) unless it runs the Ant and the Ruby, and then you've side stepped the IDE and reduced them to dumb text editors. With an Ant project, the IDE can't know that when I edit file A, it is transmogrified into file Z. (If it could, it could solve the halting problem). With Maven, the IDE implements convention, and so it know that File A is compiled to File B and then must be copied to location Z because its part of a merged war. Add JRebel to the equation and pretty much any change to the code is immediately runnable. Its dangerously easy to spike away instead of writing tests!

spullara 14y ago
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.

moneypenny 14y ago

TLDR: Maven makes hard things easy and easy things really f hard.

gchpaco 14y ago
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.
- chii 14y ago
  what would you consider something as trivial, and what is hard?
  - gchpaco 14y ago
    Building java libraries isn't really all that difficult. Not is packaging them. Damned if it doesn't take 30 lines of XML to do it in maven, but these kinds of see-spot-run situations are pretty easy. Extremely difficult in maven and five minutes work in make or ant is things like "running LaTeX to generate a PDF of some of your documentation, because it is math laden and HTML isn't suitable". This is not theoretical; I had to do this at the place that was using maven and we depended on some semi-obscure mathematical formalisms like the stable distribution. Intermediate between these two is driving things with maven plugins, which is either easy (because you're doing something trivial) or fiendishly difficult because the debugging output is terrible, the docs are worse and the only thing left to you is to Use The Source, Luke. Every nontrivial maven plugin I've ever used has tripped this at some point, be it loading config files, including the dependencies, or something else.
    - rossjudson 14y ago
      Or you could use org.codehaus.mojo:latex-maven-plugin, stick your latex and graphics in src/main/latex/<doc>, and watch it 'just work', like I do. I agree that not every maven plugin does exactly what you want it to, but a lot of them get pretty damn close, and as the authors iterate them, they gain a lot of flexibility.

tomohawk 14y ago

I've found buildr (http://buildr.apache.org http://buildr.apache.org) to be a great replacement for maven. It provides many of the capabilities that maven does, but it's also got all of the power of ruby/rake for taking care of those things that come up that the plugin/declarative approach just cannot handle reasonably. We converted our maven builds in a day and never looked back.

politician 14y ago

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.

Corrado 14y ago

I 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. :)

jebblue 14y ago

Good 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.

frugalmail 14y ago
strange, by default maven is much more strict about things, so it's hard to muck up. Perhaps you weren't creating the maven project in the format it wants you to create it in (which IMO, is a good one). Have you tried creating new projects with mvn archetype:generate ?
- jebblue 14y ago
  >> Generates a new project from an archetype, or updated the actual project if using a partial archetype. If the project is fully generated, it is generated in a directory corresponding to its artifactId. If the project is updated with a partial archetype, it is done in the current directory. I don't recall trying that however, sorry that whole description from the link you provided, it just doesn't make sense to me. In general, when I try to use Maven, Eclipse ends up complaining. Then I fix it so Eclipse is happy then Maven complains. Maybe the answer for me would really just be get the Maven and the Eclipse people to agree on how to create and manage projects with the Eclipse wizards.

wellpast 14y ago

I wholeheartedly disagree with this post, though I do like his conceptual framework of composable and contextual abstractions. I've worked on countless Maven builds and have done everything under the sun. Maven's plugin system allows you to ultimately achieve whatever you need out of your build--in the 10% case that you have a need that isn't already covered by the varied plethora of plugins out there. You can even call out to Ant using the antrun plugin. I've found so much simplicity, reliability, continued payoff in my use of Maven. I've heard complaints but usually from people that refuse to understand how it functions declaratively. Declarative systems like Maven ask that you learn something first, and then reward you infinitely if you do; imperative systems let you do something immediately without learning a model, but then make you infinitely pay for it.

frugalmail 14y ago
brilliant summary.

Uchikoma 14y ago

Maven just works and if you stay within it's intent, it does it's job. We use Maven with Bamboo for continuous integration and it just works. We play with the idea to move to Gradle b/c it's more powerful, but the effort is non trivial and the real benefits - beside the 'but it's programmable' - not clear.

lmm 14y ago
"It's programmable" is a downside here. You do not want your build system to be turing-complete; keep it simple, and Maven enforces that.

Uchikoma 14y ago

After 3 years of SBT for Scala development, which plainly does not work, b/c SBT developers do not like simplicity (the irony!) and are more interested in doing cool stuff than stuff that works, I'm only a small push away from going back to Maven/Zinc, that favors 'just works and you can't shoot yourself in the knee with an arrow' over 'powerful'.

lmm 14y ago
Do it. I've been building Scala with maven for years; it just works.

sabalaba 14y ago

The author didn't provide any background about the original Knuth "Literate Programming" paper and subsequent review by McIllroy. Knuth was using that code to demonstrate Literate Programming style. While the quote / anecdote was taken a bit out of context, I agree with the fundamental idea: code reuse. [1] http://en.wikipedia.org/wiki/Literate_programming http://en.wikipedia.org/wiki/Literate_programming [2] "Literate Programming" http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf

NeillAlexander 14y ago

"Once you start fighting with Maven, it’ll never return to the rosy days when your relationship was young." The key is, you don't start fighting with Maven. "The philosophy of Tai Chi Chuan is that if one uses hardness to resist violent force, then both sides are certain to be injured at least to some degree. Such injury, according to tai chi theory, is a natural consequence of meeting brute force with brute force. Instead, students are taught not to directly fight or resist an incoming force, but to meet it in softness and follow its motion while remaining in physical contact until the incoming force of attack exhausts itself or can be safely redirected, meeting yang with yin." (http:// http:// en.wikipedia.org/wiki/Tai_chi_chuan) If you fight with Maven, you will lose. If you meet it in softness and follow its motion you will attain build enlightenment...

traxtech 14y ago

Imho Maven, despite its wide range of plugins and extentions mechanisms, is quite "convention over configuration" (cought cought) and really is made for projects that can adapt to its conventions, and to the popular Java artifacts layouts. The problem is, when it does not suits you, the competition is not really well known. Gradle maybe ?

deltasquared 14y ago

For me personally, leinigin is why I don't use Maven that much ^_- Also, you would be surprised just how much "Java" programming you can do with a decent XML editor. IDE's are overrated.

nichols 14y ago

better link: http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html http://kent.spillner.org/blog/work/2009/11/14/java-build-too... After about a year of experience with Maven, I find that: * The "surefire" plugin is named ironically. The build often fails without a message about what unit test failed. * Maven is extremely slow. Eclipse builds the source in 30 seconds max; Maven takes 5 minutes. * Maven's output is extremely verbose, but if anything goes wrong, it "helpfully" tells you to rerun it with -X -e to get the actual error message and stack trace. You can run it with -X -e all the time if you want, but I think it generates so much output that it actually slows down the build. Yes, really. * There are a lot of things you just CANNOT DO in Maven. One example is bundling a Maven plugin together with the rest of your Maven source and use that same plugin elsewhere in the project. It fails during the early phases of the default lifecycle because the plugin isn't installed yet. But only by getting to the later phases of the lifecycle can you install the plugin. But you can't do that because the early phases fail. An infinite cycle of despair is right. * Even the most trivial project takes a few screenfuls of XML to set up in Maven. * Maven's dependency management is poor, too. If you have some library A that pulls in B, and another library C that pulls in a slightly different version of B, you can get misbuilds. It's your job to identify and fix these problems. They will show up at runtime. And let's not even talk about SNAPSHOT and how horribly that can go wrong. * Maven is also known for pulling in tons of unnecessary dependencies. But hey, you don't mind 50 more megabytes of jars on your CLASSPATH, do you? I was honestly expecting the article to address some of these points, instead of vague philosophical ramblings. Seriously, Maven is horrible. This article gives you no inkling of just how bad it is.

commentator 14y ago

I like this one: What has Maven ever done for us? http://www.wakaleo.com/blog/what-has-maven-ever-done-for-us http://www.wakaleo.com/blog/what-has-maven-ever-done-for-us :-)