Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

51–60 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#51
post #3

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.

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.

Re: Why Everyone Eventually Hates or Leaves Maven

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

Re: Why Everyone Eventually Hates or Leaves Maven

#53
post #3

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.

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

Re: Why Everyone Eventually Hates or Leaves Maven

#54
post #44
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).

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?

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?

Re: Why Everyone Eventually Hates or Leaves Maven

#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 screwdriver over a drill.

Re: Why Everyone Eventually Hates or Leaves Maven

#57
"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!

Re: Why Everyone Eventually Hates or Leaves Maven

#58
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?"

Re: Why Everyone Eventually Hates or Leaves Maven

#60
I've found buildr (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.
Post reply on HN