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

81–90 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#81

Post by andrewflnr »

rjzzleep wrote: post #45

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 even though having completely different intentions, shows the parallels quite well, imho

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#82

Post by jshen »

jamieb wrote: post #79
eranation wrote: post #74

Earlier quoted context omitted.

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

One is reproducible. One isn't. YMMV.

Well in ruby you could use bundler and it becomes

gem 'gem-name' # in Gemfile

$ bundle install

Re: Why Everyone Eventually Hates or Leaves Maven

#83

Post by drivebyacct2 »

chii wrote: post #75
dingfeng_quek wrote: post #67

Earlier quoted context omitted.

I once did an Ant to Maven conversion job on around 10 mature projects I didn't code. So that a large enterprise can move over to Maven and reap the productivity benefits. Various Maven modules were restricted, including Antrun. Because the projects are old and tied to their directory structure of resources, it was more practical to script in Maven rather than follow conventions. Scripting in Maven was quite... chall…

> the problems arising from Maven also stems from the organization's context. that's just euphemism for not following maven's conventions, which is where most people's complaint about maven stems from. You either do things the maven way, or the highway. Twisting maven to do what _you_ want, but not how maven likes it is just asking for disaster.

Ding ding ding. "Scripting maven" sounds like a nightmare. And rightly so. (and if I'm scripting a java build process, I'll take a bash script over Any any day of the week.)

Re: Why Everyone Eventually Hates or Leaves Maven

#84

Post by wellpast »

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#85

Post by yajoe »

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…

Thank you for espousing the Maven opinion. I would take your argument a step further and explain that mvn fits into common development workflows much the same tr fits into the word-counting example. Mvn is composable.

Let me illustrate what we do at work to explain. We use Jenkins as a build server and a hosted git repository. Every accepted pull request to mainline-dev is picked up by Jenkins, Jenkins runs mvn test on the commit, if the build passes, Jenkins integrates the change into mainline-stable, and Jenkins runs mvn deploy to get the latest build on a mainline-stable server.

Setting up this workflow required little customization because mvn's output was well-defined and designed to be composed within other environments, and jenkins is one common place that understands it. So are the IDEs at your work. So is the next person to tweak the environment who can look at docs to figure out what's going on. It's no different than how sed knows how to interpret tr's text output.

Does this workflow work for everyone and every language? No, not at all. Does mvn the tool work for everyone and every language? No. But I see it as an example how mvn, a build tool, fits into larger process and is a composable tool the author lauds.

P.S. The biggest benefit for our shop is twofold:

1) Dependencies get resolved automatically in all environments. Unlike my last gig, developers run the same version of libraries as the prod machines do.

2) Developers run the same test cases locally as jenkins does. We've only had one build break.

Re: Why Everyone Eventually Hates or Leaves Maven

#86

Post by zaphar »

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#87

Post by gchpaco »

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…

A correction I should note; the broken json gem was 1.4.3.

Re: Why Everyone Eventually Hates or Leaves Maven

#88

Post by gizmo686 »

laureny wrote: post #55
dasil003 wrote: 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…

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

Re: Why Everyone Eventually Hates or Leaves Maven

#89

Post by gchpaco »

chii wrote: post #77
gchpaco wrote: post #66

Earlier quoted context omitted.

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 .

what would you consider something as trivial, and what is hard?

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#90

Post by [deleted] »

laureny wrote: post #55
dasil003 wrote: 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…

[deleted]
Post reply on HN