Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

141–150 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#141
better link: 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.

Re: Why Everyone Eventually Hates or Leaves Maven

#142
post #55
post #7

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 ba…

> 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 screwd…

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

All analagies suck, but let me just refine this one by saying that the unix philosophy is like preferring a toolbox with a screwdriver, a wrench, a saw, a hammer and other simple tools vs a power drill—the power drill is great for driving screws but it's completely useless for other tasks, and it won't necessarily fit into tight spaces that a small screwdriver would.

Re: Why Everyone Eventually Hates or Leaves Maven

#143
post #137
post #126

Earlier quoted context omitted.

I think much of Java programming we are talking of today is basically using the IDE. Opening a file and reading from it takes tens of lines in Java, and that's just a trivial task. Stuff like that is better left auto generated. You don't learn Java these days, you just learn eclipse. Much of the magic is happening in auto complete. I am not sure who picks up a book to learn java these days.

> Opening a file and reading from it takes tens of lines in Java, Some of the bad Java is because of missing abstractions, most of it is because of badly designed api. http://paulbuchheit.blogspot.in/2007/05/amazingly-bad-apis.h... For your particular example, the api has been better since Java 5. import java.util.Scanner; import java.io.*; public class ScannerTest { public static void main(String[] args) throws File…

> I code in vim with eclim. There is nothing to be gained by manually writing the code for getter setter, or find-replace an identifier, or write placeholders for n methods of an interface...

None of which is necessary in better languages. I believe that was the parent's point.

Re: Why Everyone Eventually Hates or Leaves Maven

#144
post #137

Earlier quoted context omitted.

> Opening a file and reading from it takes tens of lines in Java, Some of the bad Java is because of missing abstractions, most of it is because of badly designed api. http://paulbuchheit.blogspot.in/2007/05/amazingly-bad-apis.h... For your particular example, the api has been better since Java 5. import java.util.Scanner; import java.io.*; public class ScannerTest { public static void main(String[] args) throws File…

> I code in vim with eclim. There is nothing to be gained by manually writing the code for getter setter, or find-replace an identifier, or write placeholders for n methods of an interface... None of which is necessary in better languages. I believe that was the parent's point.

> None of which is necessary in better languages.

It isn't necessary in any language, but it sure is useful.

I don't know what you mean by better languages, but I program comfortably in variety of languages(Ruby, Python, C, C++, Java, Clojure, Lua, Racket, go, JS, perl...) and haven't found a single language in which context aware auto-complete, assisted re-factoring, looking up inline documentation etc isn't useful.

Re: Why Everyone Eventually Hates or Leaves Maven

#145
post #41

> 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…

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#146
post #144

Earlier quoted context omitted.

> I code in vim with eclim. There is nothing to be gained by manually writing the code for getter setter, or find-replace an identifier, or write placeholders for n methods of an interface... None of which is necessary in better languages. I believe that was the parent's point.

> None of which is necessary in better languages. It isn't necessary in any language, but it sure is useful. I don't know what you mean by better languages, but I program comfortably in variety of languages(Ruby, Python, C, C++, Java, Clojure, Lua, Racket, go, JS, perl...) and haven't found a single language in which context aware auto-complete, assisted re-factoring, looking up inline documentation etc isn't useful.

Generating get/set and abstract method bodies is only necessary in Java.

Find-and-replace, auto-complete and docs are of course useful generally.

Re: Why Everyone Eventually Hates or Leaves Maven

#147
post #55

Earlier quoted context omitted.

> 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 screwd…

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 () { public int compare(E o1, E o2) { return 01.val-02.val } } (You cou…

This is correct, I just don't like Java. IDEs are really beside the point; but the fact is there is no IDE that supports the breadth of languages that vim or emacs support. And there's certainly no IDE that I would want to run over SSH to machines spanning oceans, whereas vim copes incredibly well.

Re: Why Everyone Eventually Hates or Leaves Maven

#148
post #7

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 ba…

Very similar to my view of Emacs. It doesn't matter whether I'm on my Mac, my work Ubuntu, or SSHed into a Debian server, my development environment is the same. With Cygwin, I can even make it work on Windows (heaven forbid! ;). It is nice to have the biggest context change be "where is my source here?"

Emacs runs native on Windows; no need for Cygwin.

Re: Why Everyone Eventually Hates or Leaves Maven

#149
post #9

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

As part of your build were you wiping out your local repo ( ~/.m2 ) for some reason? It would only need to check if you don't already have the version specified in your pom in your local repo.

Yes - all our builds are done from zero state i.e. and empty directory. We even deploy a new JVM each time (as we have to test against 3 different JVMs).

Re: Why Everyone Eventually Hates or Leaves Maven

#150
post #144

Earlier quoted context omitted.

> None of which is necessary in better languages. It isn't necessary in any language, but it sure is useful. I don't know what you mean by better languages, but I program comfortably in variety of languages(Ruby, Python, C, C++, Java, Clojure, Lua, Racket, go, JS, perl...) and haven't found a single language in which context aware auto-complete, assisted re-factoring, looking up inline documentation etc isn't useful.

Generating get/set and abstract method bodies is only necessary in Java. Find-and-replace, auto-complete and docs are of course useful generally.

"Generating get/set and abstract method bodies is only necessary in Java" On smalltalk instance variables are private, so if you want get/set it's value you need a getter/setter. You can argument that this is bad oo design, but it's not java exclusive.
Post reply on HN