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

121–130 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#121

Post by tieTYT »

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…

"interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json 1.4.2, and many other worse things."

This seems like a java problem more than a maven problem. In fact, I don't really know what you could do about this. Maybe OSGi has a solution.

Re: Why Everyone Eventually Hates or Leaves Maven

#122

Post by meaty »

jomohke wrote: post #44
meaty wrote: 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?

Yes we have disabled the local cache. Our build machines are not stateful - the environment is wiped before each build intentionally. We have had problems where maven caches are poisoned and the builds start failing randomly which cost us a lot of time half way through a major release.

Re: Why Everyone Eventually Hates or Leaves Maven

#123

Post by NeillAlexander »

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

Re: Why Everyone Eventually Hates or Leaves Maven

#124

Post by brazzy »

tieTYT wrote: post #121
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…

"interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json 1.4.2, and many other worse things." This seems like a java problem more than a maven problem. In fact, I don't really know what you could do about this. Maybe OSGi has a solution.

Um... his example is a Ruby library. It's a totally language-independant problem.

Re: Why Everyone Eventually Hates or Leaves Maven

#125

Post by benjaminwootton »

revscat wrote: post #37
benjaminwootton wrote: post #10

Earlier quoted context omitted.

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.

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.

It's two lines...

mvn archetype:generate mvn package

Re: Why Everyone Eventually Hates or Leaves Maven

#126

Post by kamaal »

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…

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#127

Post by lmm »

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…

>- submitting code to a code review site like Gerrit.

Why would you want your build tool to do that?

>- generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily).

There are plenty of plugins to do that. If you want one that doesn't exist, write your own. It's not hard, and means this operation will be encapsulated in a structured, testable, reusable way. If you're generating code in an ad-hoc, specific-to-a-single-project way, you're doing it wrong.

>- integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?).

Yep, I've used it. It works fine.

>- code coverage analysis (yes, there's a Maven plugin. You ever used it?).

Yep, I've used it. It works fine.

>- FindBugs style analysis (yes, there's a Maven plugin. You ever used it?).

Yep, I've used it, it works fine.

>- interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json 1.4.2, and many other worse things.

Huh? You can depend on a specific version, a range of versions, or a range with gaps in. You can't depend on two versions of the same library because it's impossible to set the classpath up like that, but that's a limitation of Java, not maven.

>- C code (through JNI or anything else, a perfectly reasonable thing to want to do).

There are ways to do this, I'll agree it's not pretty. If you want to use another build tool for those projects that include C code that's fair - it should be a minotiry of your projects.

>- deployment.

Not the appropriate tool for it.

Re: Why Everyone Eventually Hates or Leaves Maven

#128

Post by lmm »

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

Sounds like they've cocked up the jars they've produced; you should never have to use exclusions, and it's possible to have a dependency that can be satisfied multiple ways with a default, so you shouldn't need to choose the driver separately if you don't want to. Much of that xml file is what already exists for your project. So the fair comparison is with the section: org.seleniumhq.selenium selenium-java 2.28.0

So: you need a groupId; we've learnt through painful experience that this is a good idea to prevent collisions rather than just using the name. That said, your tool should autocomplete it if there's only one option.

You need to specify a version; this is 1000% the Right Thing. Again, your tool will give you a list to choose from.

And yeah, it's a bit of a verbose way to specify those three pieces of information; the point is for it to be easy to automatedly manipulate the pom file.

Re: Why Everyone Eventually Hates or Leaves Maven

#129

Post by traxtech »

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 ?

Re: Why Everyone Eventually Hates or Leaves Maven

#130

Post by lmm »

shadowmint wrote: post #38
michaelt wrote: post #27

Earlier quoted context omitted.

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?

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

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

Post reply on HN