
Why I don’t like Maven - shawndumas
http://johlrogge.wordpress.com/2010/12/14/why-i-dont-like-maven/
======
smoyer
I love Maven and have been what I'd call a power user for at least five years.
However, the first time I heard of it (and tried it), I hated it. Until you
get your head around the idea that you're describing "what" you're building
rather than how to build it, you'll feel an impedance mismatch.

And I didn't begin to feel mastery with Maven until I started writing plug-
ins. If you really want to understand your tool, then try extending it. I've
never had issues with Maven builds missing files, etc. and I'm not really sure
how that happens. On the other hand, the fact that the project structure is
almost always the same from project to project lets me successfully dive into
projects I've never touched.

But Maven can be complex, especially if you're not careful to segment your
project into sub-projects and modules. There are parts that are best learned
by working with someone who's already mastered the build system. In any case,
I think make/autoconf are harder to grasp than Maven, and I've never hated it
the way I do when I'm programming in XML (Ant).

~~~
emmelaich
Like so many, I love and hate it. I can see that it helps at the large scale -
big projects, many of them. It also helps people come in cold to a project.

On the other hand, unfortunately it doesn't scale to the low end.

I had a task just to transform a jar file. With Maven it took hours of
scratching my head, finding the assembly plug-in, having Maven download 100Mb
of stuff; all to do what would take a minutes of development time and
executation time total to do in Python or Perl.

That makes you scream inside.

~~~
timv
Heh, I have the totally opposite view...

Maven is perfectly fine for small projects, but a totally waste of time at the
large scale.

If your project is a few hundred classes, that use _some-popular-web-
framework_ and _some-orm_ , and get packaged into a single WAR file, then
Maven is simple, it works and it lets you avoid thinking about the build.

If your project is thousands of classes using a variety of technologies
(Corba, JMS, Web, etc) with layers of dependencies, then Maven _should_ help,
since it _should_ allow you to manage all those technologies through a similar
process, but it just collapses under the strain.

The bits that tend to get in the way (some of this is probably specific to
Maven 2, but I got burnt enough back then that I'm not willing to revisit it
all and see what happens with Maven 3)

Despite multi-module being the right way to solve things (both the Maven
team's opinion and mine) it works really badly. If you want to compile & test
your whole project each time, then you're all good, but if you want to cut
your build process down and just recompile the modules that you're working on,
you're going to lose most of that time saving in trying to wrangle Maven into
doing things properly. The main issue is the dependency management is all
built around the idea that you only ever depend on jar files in a repository.
So, in a multi-module project where you actually want to depend on "the source
code sitting in a sibling directory", things go wrong.

Despite Maven's theories about having a standardised project model, too much
ends up being left to the plugin authors. If you're using more esoteric
plugins (e.g. the Corba IDLc plugins) then you'll get caught out by issues
that the plugin authors didn't think of. _Plugin-X_ looks for a resource file
on the classpath (but only the _main_ classpath, not the test one), _Plugin Y_
looks for its resource file on the file system, _Plugin Z_ will look for a
file on the classpath, but crashes if that file is inside a jar, but you need
to reference a jar because the file is coming from another module in your
multi-module project, and you can only express dependencies on jar files. So
to work around that you add a step in your build to unpack the jar into a
temporary location and add that location to the classpath. And you though
maven wasn't procedural.

One artifact per module is a nice idea thought up by people who assumed that
their experiences were diverse enough to solve everyone else's problems.
Unsurprisingly they're wrong. But to keep maven happy you split your project
into dozens of modules each with 1 artifact. But that makes your build even
slower, and creates even more issues with managing the dependencies between
modules. And even if you do that, you still end up hacking your pom to create
more than 1 artifact because sometimes you really need to.

Handling test support code in a multi-module project is painful. Well written
tests need supporting code. But that is neither "test" code (because test code
is not exported out of your module) nor "main" code (because you don't want to
ship it). So either, you create extra modules to handle testing. In the worst
case, you need to split each module into 3 - the _main_ code, the _test
support_ code, and the actually _tests_.

So, in summary, the pain you're feeling with a small project, is just
multiplied exponentially as your project grows.

------
hobb0001
I've beat this drum before, and I'll beat it again here. The build
configuration for every large project eventually becomes turing complete
(requiring loops, conditionals, subroutines, what have you). Why is it then,
that every new build tool that comes to town is declarative? Just give me a
nice library full of handy build functions and I can write a build script in
fewer lines than any build tool configuration -- and be more readable to boot.

------
ExpiredLink
> _Maven assumes there is one right way to build for everyone_

People who accept this are (the majority of) happy Maven users. People who
fight Maven write angry blog posts.

~~~
threeseed
So true. Maven is the PostgreSQL of build tools.

~~~
ArtB
I fail to see the connection... please explain.

------
lsd5you
I happen to think that maven is a good idea in principle, but poorly designed.
One fundamental issue is that it does not distinguish between what I call
'products' and 'modules'. Modules have transitive dependencies and tend to
have a common structure, and products do not.

When you are building a product (e.g. an installer, some documentation, a
website ... etc.) with the build tool, what you create is an artifact, that
once built you can treat independently of its dependencies. A module is
library code, and when you depend on it you implicitly depend on its
dependencies as well.

Build languages/dsls are a complete intellectual cul-de-sac. Java is a
perfectly acceptable (in fact quite decent) language for doing build tasks.
There is nothing in ant that cannot be equally concisely written in java,
given the right library support.

I have written more this subject in the articles on the website.

<http://www.ebuild-project.org/>

The website is not completely upto date, the latest version is 0.8.4.

~~~
Evbn
Java is unwieldy as a configuration language. Python (or a restricted subset)
is a lot cleaner.

But to replace Java by XML (as ANT/Maven does) doesn't help.

~~~
lsd5you
I think this misses the point.

Grouping ANT/Maven together because of XML is a very superficial association
to make. ANT despite what it claims is essentially an inflexible programming
language, which offers very few benefits over java (and many disadvantages),
except that it is interpreted (not compiled), has a library of build tasks and
can be stuck in the root of a project without looking like source code. XML is
a big issue in ant because it is a very poor choice for writing a programming
language.

Maven is a build framework, into which you make your program fit, by
decomposing it into maven projects ... etc. etc. XML is a perfectly good
choice for configuration here. The core problem with Maven is poor design. For
one, it has tried to make things simpler than they are, and does not recognise
that some programming projects are fundamentally not amenable to a module
structure (i.e. what ebuild calls products). It also makes developing across
the dependency boundary (i.e. your program + the library) very cumbersome
indeed.

------
rtperson
> I especially find Maven unreliable in combination with eclipse.

Well there's your problem right there. Use Maven with Netbeans, and the
integration between the two is so slick you'll wonder why you didn't use it to
begin with. My biggest complaint in Netbeans now is that it doesn't have
_equally_ slick support for SBT and Gradle, but that's just because I've been
spoiled.

~~~
johlrogge
Actually, it's one of the problems, not /the/ problem. There were many more
listed :) I would really like to sit down with a netbeans fan to convince me.
I have tried my hands on it a few times but I never understood why some people
use it. Intellij, sure, netbeans... not convinced :/

------
jhawk28
Most of these issues have been fixed with Gradle. Gradle still has some
immaturity issues, but its overall a better system that takes the good parts
of maven like dependency management and build environment conventions.

------
cletus
Oh my God I'm sick of people equating IDEs (in the negative sense) with
Eclipse. This goes beyond this post (eg typically emacs/vim users make
judgments about IDEs based on having once used Eclipse). But take this
statement:

> I especially find Maven unreliable in combination with eclipse.

Indeed. I have first hand experience with this. My team has a diehard Eclipse
user who has added a bunch of random configuration plugins to Eclipse
basically to make Eclipse work with Maven.

Compare this to IntelliJ. You can open a Maven project (even a multimodule
Maven project) _directly_ in IntelliJ. There is no project
importing/conversion. It just works with the native Maven project model.

There are plenty of things to dislike about Maven but this isn't one of them.

The author is correct about Maven documentation generally being terrible. At
one point I wanted to do something as simple as creating symlinks in the
target directory instead of copying files. This would greatly ease doing
Javascript development, for example.

Well there's a Junction plugin for Maven that alleges to do this. However it
hasn't been updated since 2007 and relies on something no longer in a Maven
repo that I could find.

But here's the point I most disagree with:

> Maven assumes there is one right way to build for everyone

A lot of people have this opinion (and prefer Ant, Gradle or something else as
a result). I do not share this view. I like that Maven is opinionated about
things like project structure.

Why? Because left to our own devices engineers are terrible at making these
sorts of decisions. We all have a tendency to focus on some weird aesthetic
and overstate its importance at the detriment of consistency across teams and
projects.

I've had this argument with coworkers in relation to us having a very strict
style guide for our code [1]. Opponents call this an obstacle getting in the
way of getting something done and it has a cognitive cost of internalizing
what is essentially useless information and arbitrary standards.

Obviously said people haven't worked in a large engineering organization where
different teams would otherwise have different line lengths, curly brace
styles, indenting levels and so on. It's a good thing there's a central set of
conventions for this stuff. It avoids pointless "wars" about where curly
braces should go.

I feel the same way about Maven's archetypes. Fact is, you can look at any
Maven WAR project and know where to find pretty much everything. You can't say
the same about any Ant project.

Just like with code style, people have an exaggerated view that their
particular way of doing things is right and super-important.

Being consistent is often more important than being right.

Being right is subjective more often than it isn't.

In the end the author states:

> I think Maven works fine but in the past some logical choices have been made
> that do no longer make sense

which kinda makes and misses the point. He's right in that it does work fine
for all its warts. But changing things like XML (for YAML or SBT's DSL or
whatever) is pretty much a change for change's sake at this point.

Maven is one of many tools that isn't cool but is certainly good enough. There
are really bigger things to worry about. How much time do you spend editing
build files anyway?

[1]: <https://code.google.com/p/google-styleguide/>

~~~
timv
_> Maven assumes there is one right way to build for everyone_

 _A lot of people have this opinion (and prefer Ant, Gradle or something else
as a result). I do not share this view. I like that Maven is opinionated about
things like project structure._

Well his opinion is perfectly true - Maven does assume there is one right way
to build for everyone. You're disagreeing about whether it's a _bad_ thing.

And here's the deal - for the 95% (or more) of projects where "The Maven Way"
works, it's a good thing, for all the reasons you've stated.

But not every project fits into that, and one of Maven's limitations is that
once you start to push at its boundaries, it falls apart. It doesn't provide
enough flexibility to be able to stretch it into places it wasn't intended to
go. And so, once your project his that point you either need to fight the
tool, or throw it out and use something else. Neither is particularly
desirable.

 _Maven is one of many tools that isn't cool but is certainly good enough._

For most cases, yes, but not always. No matter who you are, your experience is
not universal enough to draw those conclusions for other people's projects.

 _How much time do you spend editing build files anyway?_

Personally? Enough to have run into all sorts of limitations in Maven.

Not everyone is working on "Maven WAR project". There are projects with full
time build engineers. Even on small projects (in terms of lines of code) if
the artifacts you're producing are non-standard, then you can spend days (or
even weeks) wrestling with maven to get the project under control.

Maven makes the easy things trivial, the average things easy, but it also
makes the hard things nearly impossible. For the 95% that's a fine trade-off,
but if you're not in that group then Maven is not going to be your friend.

~~~
mtrimpe
Maven is very, very customizable.

I've built ETL libraries that use a completely custom lifecycle (pre-/post-
extract, extract, transform & load) in Maven with a directory structure to
match.

If you can't code in Java that will be hard, but it's similar to me
complaining about Puppet because I can't figure out it's architecture fast
enough since I don't know Ruby well enough.

P.S. Not saying you can't code in Java, but the original author did indicate
the mere fact that it was Java was problematic.

~~~
johlrogge
Yes, the original author (me) did indicate that Java was a bad choice but not
for the reasons you assume here but for the reasons I clearly stated in the
post :)

Most of them being related to that Java is a compiled language so you often
find yourself in a situation where you wonder about plugin internals but the
actual source the plugin was built from is elsewhere. That in combination with
that extensions needs to be compiled and distributed which requires
infrastructure to "build the build". Sure it's easy to google and download the
source, even recompile, setup a place where the plugins can be used from
(custom and patched ones) but it is still extra overhead that would not be
needed at all with (for instance) an interpreted language.

An interpreted language is simply a more sensible choice for these kind of
things. The developers of SBT understood this and made sure the buildfile and
plugins are distributed as source and compiled by SBT to make this extra step
go away even if the buildfile is written in Scala.

~~~
mtrimpe
Indeed. From what I can tell it seems that your post is actually taking aim at
Java and it's ecosystem and how Maven embodies that more than against Maven
itself.

You're framing it as an attack against just Maven though..

------
ubersoldat2k7
What I find most of new users of Maven fail to grasp is that it's not designed
to work as Ant or Make. There's a reason jelly support was dropped in M2 The
best thing about Maven is that once you understand what it's supposed to do,
it does a great job at it. But when you find your self doing more custom
stuff, it's better to extend your build process with the tools which are
designed for this and let Maven handle the stuff it does fine. And yes, Maven
support in Eclipse is... crap, because Eclipse is designed around Ant-like
tools. Sorry to the guys who maintain the m2-plugin because it has to be a lot
of work, but if you're using Maven, you'd better go with NetBeans or any other
IDE. In my case, I do all the builds from the CLI and don't bother to
integrate Maven with the IDE.

------
toolslive
It has been a long time since I used maven, but I used to be a user. The
biggest problem with maven (except for quality, which I think is temporal) is
that you cannot reproduce a build.

The simple task of 'given a jar artifact(1), and its md5, full source code and
pom, reproduce it from scratch' never works. (One of the reasons being the jar
tool that stores .class file dates inside the jar).

Another reason is that maven self-updates, and sometimes this gets in the way
of being able to build an older project. I'm pretty sure there are several
jars in biblio that cannot be recreated (never mind the md5) without
significant hacking.

(1) there is a difference between 'artefact' and 'artifact', but somehow the
semantics became confused.

------
Gravityloss
I like the style of this article. It is confident yet has simple humility and
openness. One rarely sees that. For example, when I write or talk about some
piece of software, it tends to be either the best in the world or
incomprehensibly incompetent.

~~~
johlrogge
Thank you! That was really nice feedback. I'm glad you liked it

------
v1r3n
+1 for Gradle. Yes, it is still quite new, but in return the documentation is
pretty good and when you want to do something, that is not available out of
the box, extending is quite easy. And yes, groovy rocks!

~~~
vorg
Gradle would do well to ship with other languages to increase share with those
who want to use a more professional language with it. The big problem with
browsers is they're limited to Javascript.

------
DavidPlumpton
Maven is ideal for when teams of programmers work on a number of projects. How
do you build this project from long ago? How do I set up a new dev machine?
I'm moving to this new project, how does it work? We've got a new guy starting
tomorrow, how will he know what to do? etc. etc.

I suspect most people who criticise maven haven't worked in corporate
environments where there are just a lot of projects, a lot of people, and a
lot of churn (both in people and projects). That's where maven is a life
saver.

~~~
crdoconnor
Everything I hate about Java in some way traces back to the idea that "making
it like this will make it more suitable to corporate environments".

Corporate environments want droneish, politically correct, interchangeable
programmers who very rarely step outside of their predefined, straitjacketed
roles.

------
bni
One thing I dont get about maven is why the version number get embedded in the
jar's filename. Everything has to be rebuilt when you switch to a new branch
that has a different version number, deployed files cant just be "copied over"
etc. Seems a huge impediment to any kind of efficient deploy system.

I am not that well versed in build systmes, but I have never seen another
build system that does this. Usually version numbers is stored in some meta
data not in filenames.

------
pswenson
Once again, java could stand to learn from Ruby. Maven is terrible for
automation (XML is a lousy scripting language).

Gradle? It's better than Maven, but they picked the wrong scripting language.
Builds should be interpreted, not compiled. It's painful to leverage code that
you need to build as you are in a catch 22 situation - can't reference a class
in a gradle file that hasn't been built yet.

------
stiff
The idea of describing a build in XML is so ridiculous only Java people could
have invented it, "why I don't like Maven" is hardly interesting, "why the
hell would anyone like Maven" is a good question. If you remember Linus
Torvalds describing CVS vs. Git, I think you could say the same of Maven vs.
anything actually reasonable.

~~~
konradb
Is it verbosity that makes it unreasonable to you? What would your ideal way
of describing a build be?

------
X-Istence
Maven in my experience may simply be an extension of Archive.org ... at least
it feels that way when I run mvn on some of the Java projects at work and I
download half the Internet before the build even starts...

