Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#111

Post by jshen »

frugalmail wrote: post #96
jshen wrote: post #82

Earlier quoted context omitted.

Well in ruby you could use bundler and it becomes gem 'gem-name' # in Gemfile $ bundle install

Until you want to do it on a system you just want binaries. Or until you need to guarentee the version of the library you're bundling Or you want to run on something other than a MAC-in-crap, like Linux. RVM has the same problems. In my opinion, one is for play, and one is for work. If you just want to fuck around and spew code in one long controller that looks like spaghetti, and you don't want to worry about reprod…

It does guarantee the version, and I'll ignore the rest of the trolling.

Re: Why Everyone Eventually Hates or Leaves Maven

#112

Post by Uchikoma »

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

Re: Why Everyone Eventually Hates or Leaves Maven

#113

Post by msgilligan »

meddlepal wrote: post #72
msgilligan wrote: post #47

Earlier quoted context omitted.

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?

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

Well, 1.4 claims to have improvements to dependency resolution, so soon you should be able to take another kick at the football soon. I'm growing to like Gradle more and more and haven't seen any problems like this. My major desire is for more/better plugins, but I do think this will become less of an issue. (I'm even hoping to write 1 or 2)

I should also mention that GVMTool is worth checking out if you're on a UNIX-based system. An easy way to install and switch between versions of Gradle and other tools: http://gvmtool.net

Re: Why Everyone Eventually Hates or Leaves Maven

#114

Post by chrismaeda »

berlinbrown wrote: post #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, ba…

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#115

Post by [deleted] »

eranation wrote: post #74
jamieb wrote: post #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…

You can like maven or hate it, but why can't it be a bit simpler? e.g. take this selenium install instructions ( http://seleniumhq.org/docs/03_webdriver.jsp ) Ruby: gem install selenium-webdriver Java (with Maven): 4.0.0 MySel20Proj MySel20Proj 1.0 org.seleniumhq.selenium selenium-java 2.28.0 com.opera operadriver com.opera operadriver 1.1 org.seleniumhq.selenium selenium-remote-driver Then run mvn clean install

[deleted]

Re: Why Everyone Eventually Hates or Leaves Maven

#116

Post by rossjudson »

gchpaco wrote: post #65
jamieb wrote: post #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…

If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly. Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable: - submitting code to a code review site like Gerrit. - generating code (for example, a parsed SNMP MIB that you want as a Jav…

Pretty much everything you mention simplifies to "choose a phase, then add an exec plugin declaration".

Have you looked at http://maven.apache.org/guides/introduction/introduction-to-...?

Maven is particularly good at generating code for later compilation and processing. Your custom code generator just needs to put code into src/generated and it will be picked up.

Given that Maven is used to organize and build some pretty large projects out there in the real world, you might want to amend your statement from "Maven scales astoundingly poorly" to "I am astoundingly poor at scaling Maven".

It's not all wine and roses in the land of Maven, but it gets a whole lot of the job done, and done well.

Re: Why Everyone Eventually Hates or Leaves Maven

#117

Post by cbsmith »

timv wrote: post #71
gchpaco wrote: post #65

Earlier quoted context omitted.

If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly. Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable: - submitting code to a code review site like Gerrit. - generating code (for example, a parsed SNMP MIB that you want as a Jav…

You can add pretty much anything to do with CORBA to your list. Yes there are plugins for it, but they only work in the most trivial of cases. The original article was helpful to clarifying for me why I have such a low opinion of maven - the project I was working on when Maven came out was a large complex codebase and we'd built lots of interesting things into our Ant build files. I could not work out how to ever do…

Badly written programs are far from an inevitable outcome with contextual tools. That is more a symptom of Maven's choice of a rather narrow context that has limited its appeal (that and all the ways it sucks ;-).

Re: Why Everyone Eventually Hates or Leaves Maven

#118

Post by cbsmith »

chrismaeda wrote: post #114
berlinbrown wrote: post #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, ba…

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

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#119

Post by cbsmith »

zaphar wrote: post #86
jamieb wrote: post #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…

And then the person that wrote them leaves and we're fucked. Where in the article does he say in-house tools are better? His point is about tool composability. Just because you haven't run into the wall he describes Maven having yet doesn't mean it doesn't exist. He says as much in fact. He recommends starting with maven till you outgrow it which seems perfectly reasonable.

I think you missed the point. The problem with comparability is that you have the freedom to compose things however you want to. It's not exactly uncommon for "composable" build systems to be all but inscrutable to the next guy.

The consistency of an opinionated build tool does provide some not insignificant benefit.

Re: Why Everyone Eventually Hates or Leaves Maven

#120

Post by sabalaba »

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

[2] "Literate Programming" http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf

Post reply on HN