Hacker News new | ask | show | jobs
by drivebyacct2 4898 days ago
I'll take rigid maven any day. Much preferable to some cobbled together build system that is undocumented and hard to reliably reproduce.

I'm curious what people are doing with Maven that they manage to get into such a fight with it? Although to be fair, due to issues in its dependency resolution mechanics, it can pull in incorrectly versioned artifacts without ever telling you anything.

5 comments

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

There are more options besides a completely rigid build system and cobbled together build system. There is room for something in between. I think the build tool should encourage you to use common structure but allow you deviate from that if necessary. Sometimes, Maven makes it very difficult to accomplish small tasks without writing an entire plugin.
That and don't forget: 1. The tools that can work with it [Hudson, etc] 2. The support for SVN if you want it 3. Plugins aren't the worst thing in the world. Instead of fighting arround with Tomcat to get a dev server going and deploying the artificat manually [or getting the ide to do it] you just have to use mvn tomcat7:run ... easy.
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... challenging.

In this case, the problems arising from Maven also stems from the organization's context.

> 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.)
How are you ending up with anything other than the version you specify? Dependency mismatches on versions?
More info, including an example of Maven itself shipping with mismatched versions: http://jira.codehaus.org/browse/MDEP-273

Depending on how bad the mismatch is and how carefully people maintain or break APIs between versions, it can introduce problems.

I've not been into Java enough recently to know if this is fixed or is still affecting Maven3.