Hacker News Reader

Hacker News

Comment by ExpiredLink | Hacker News Reader

Parent Full thread

ExpiredLink

Do it the Maven way and you'll have no problems.

Fight the Maven way and you'll end up in a mess.

tl;dr Understand the tools you use.

View on HN

That's fine, so long as the problem you're trying to solve is easily expressed within Maven's structure.

And sometimes, expressing it withing Maven's structure can lead to very slow builds, at least within my experience.

But perhaps I'm prejudiced; I hate maven, and have since my first experience with the Mvn 2 betas. You know when you see a new technology and you say, "this is painful now, but it's going to be worth it in the end?" I got the "this is painful now, and is only going to get worse as plugins depend on crazy ass behavior" feeling.

From everything I've seen since, I was right.

> From everything I've seen since, I was right.

Please substantiate this, as I've been using Maven for quite a while and while it isn't perfect, it's not remotely painful. And I'm not talking about just for "build this jar" projects; most of my Android apps use Maven, too, as do a number of projects of mine that have native dependencies.

(I have no problem with Gradle, either; I just generally find most of the Maven complaining to be overblown.)

Luckily, these days I don't have to work with Maven. :) - But that means I don't have any current Maven code I can distill out as examples. However, I think the blog post does a good job of laying out these problems, particularly the way that incremental compilation sucks in Maven. One example used to be some major issues we had with jasper reports. We had xml files that weren't really jars, that needed to be in a particular directory within the parent war, and had different XML files to use for different clients. So it wasn't as simple as one input, one output. Some files were shared for certain clients, some were client specific. Sometimes we depended on two different files -- one client might have one report1.xml, another client would have a different report1.xml.

This is actually pretty simple with Ant, but becomes a nightmare trying to fit into a Maven structure.

Gotcha, thanks for the response. I think a lot of why Maven doesn't bug me is because I'm not really an "enterprisey" Java/Scala guy, I use it to build more discrete and contained stuff. I had to look up what JasperReports was. :-P But I use it for libgdx projects, for Android stuff, and for just quick one-offs without a hitch. Before Play (which uses SBT, which I'm not thrilled about, but, anyway...) came around I strictly used embedded Jetty--I'd use Dropwizard these days if I was to do that with Maven again, it's great.

I've tried on many occasions to make Maven work with Eclipse but Maven nearly always finds a way to mess up Eclipse's excellent project management abilities. I'd say that if you just write code in an editor then Maven makes a lot of sense, if you use a powerful IDE like Eclipse then Maven becomes an unwieldy and unnecessary challenge.

Maven killed some great open source projects, i.e. Apache Cocoon

According to the hp Apache Cocoon is based on XML/XSLT and Spring. If it failed I bet not because of Maven ...

except that in Cocoon you are not forced to use XML/XSLT.

Try to make sample webapp using Maven 2:

http://cocoon.apache.org/2.2/1159_1_1.html

I bet you will fail thanks to some random maven quirk:)

Spring is just some Java library, XML/XSLT is too simple to break anything.

Reply on news.ycombinator.com