
Maven is broken by design - richardw
http://blog.ltgt.net/maven-is-broken-by-design/
======
koevet
I don't understand why this is still a matter of discussion after so many
years of blood and tears. Maven is dead, everyone else is moving to Gradle
(Spring, Android, Hibernate, etc.).

I have been using Gradle now for almost 3 years and I can't be happier. The
support is great, they roll out new features at a regular pace, it's fast and
incremental build WORKS.

If you work in Java and you are still stuck with Maven, please, take a look at
Gradle.

~~~
Randgalt
No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you
want incomprehensible build files ala Ant, choose Gradle. If you want standard
build files and a rich ecosystem, choose Maven.

I hated Maven until I tried the alternatives.

~~~
koevet
> incomprehensible build files ala Ant

Please, explain incomprehensible (or show an example)

~~~
Randgalt
Here's Netflix Exhibitor (which I wrote):
[https://github.com/Netflix/exhibitor](https://github.com/Netflix/exhibitor)
\- the developer who wrote the build scripts did an incredible job. I'm very
impressed. However, I don't comprehend it. Note: this was previously in Maven
and had exactly 3 POM files.

~~~
koevet
Thanks for the link.

To my eyes, the build scripts are pretty clear. I like the way the scripts are
nicely organized using 'apply'. Maybe the only script that may look complex to
someone starting with gradle is 'convention.gradle', but again, nothing
impossibly hard to grasp for a developer.

~~~
Randgalt
No at all clear to me. You think
[https://github.com/Netflix/exhibitor/blob/master/gradle/rele...](https://github.com/Netflix/exhibitor/blob/master/gradle/release.gradle)
is clear? What about
[https://github.com/Netflix/exhibitor/blob/master/gradle/lice...](https://github.com/Netflix/exhibitor/blob/master/gradle/license.gradle)?
What is "ext.year"? I don't want to learn and understand an entirely new
language for my build.

I am not able to maintain these build scripts. This is the problem with DSLs
in general. Maven isn't great, but its strength is standardization. I can look
at any Maven pom and know what it does and make changes to it.

------
Communitivity
I'm a sw engineer programming Java since 1996. I started using Maven when it
first came out as the declarative build language hooked me, and became the
local Maven expert. I've watched it grow with pride, and sometimes in anger. I
still believe a declarative build language is best, but it won't be in XML. I
suspect it will eventually be in something like OWL, whatever comes along
after OWL that fixes its issues.

So as of a few years ago I too moved on to Gradle and have loved it.

But...

Language based build systems offer more expressiveness, but that is also more
rope to hang yourself with if you get someone that doesn't know Gradle well
doing tinkering with your build. For example we had someone add a custom
checkstyle report to an Android project using Gradle. After their edits it
stopped working because of the way the Android plugin was designed, bringing
the build down for several hours. I came in, rewrote the Gradle build file to
workaround the issue and it worked. Then I documented to the person why it
hadn't worked and what I did to fix it.

As with the adoption of anything that gives you more rope to hang yourself
with, it's a necessary piece of Gradle adoption to document your practices and
train your team well.

~~~
twic
"I documented to the person" \- that is a euphemism i will have to remember.

Yeah, I documented it to Jim. That's a documenting he won't forget in a hurry,
make no mistake.

------
frankzinger
Incremental builds: I am working at a Java shop at the moment and was amazed
to find that even the resident Maven experts clean before every build. To me
incremental builds are one of the most important functions of a build system,
but it seems that users of Maven and other well-known build systems used in
the Java world have given up on it because it just doesn't work. So anything
which fixes even only this problem would be a step in the right direction.

~~~
jpollock
I read how TeamCity did their incremental builds and wrote my own script. I
drop an anchor, detect changed files and then build up a list of modules that
need to be rebuilt. I then tell maven to build those modules and their
downstream dependencies.

Speeds things up a tonne.

[http://blog.jetbrains.com/teamcity/2012/03/incremental-
build...](http://blog.jetbrains.com/teamcity/2012/03/incremental-building-
with-maven-and-teamcity/)

------
hrjet
One thing which I detest about maven, it uses http by default. Getting it to
use https requires a lot of work[1] so many don't use it.

By default, not only are you downloading a truck load of jars from the
internet and running them locally, you are fetching them over an insecure
channel!

[1]: [http://maven.apache.org/guides/mini/guide-repository-
ssl.htm...](http://maven.apache.org/guides/mini/guide-repository-ssl.html)

~~~
nl
Honestly, so what?

What is HTTPS supposed to protect against in this case?

1) If you are using it to protect against snooping (why?!) then you must
realise that the logs of many Maven repositories are effectively public (eg, I
believe Apache committers can access the repo.maven logs pretty easily). For
protection against snooping, use a local repo.

2) If you are expecting it to protect you against tampering in transport, then
you are better off using a local repo (again). It's much more likely artifacts
are tampered with at the remote repository rather than during the transport
phase.

~~~
andor
_It 's much more likely artifacts are tampered with at the remote repository
rather than during the transport phase._

MITMing the public wifi at some coffee store is much easier than breaking into
the official Maven repositories. At least I hope so. That's why RPM and DPKG
packages are signed.

~~~
Terretta
Ok, but the impact of hacking the official repo, vs sitting at some coffee
store hoping someone in the same coffee store builds a project using a
particular lib you have code to modify on the fly while you mitm that exact
repo pull?

He said much more likely the repo is tampered with. Easy to see why. This
coffee shop scenario, they'd have to be targeting you personally and know your
habits and your build and code they need to target you. In which case, https
is far from your biggest concern.

~~~
kilburn
Replace "coffee shop" by "software conference hall" and "specific lib" by
"current log4j/junit/whatever _very_ common library you want".

Suddenly it's a lot less targeted attack. Moreover, the "victims" should be of
much higher profile than your regular student downloading an obscure library
whose repo you managed to hack.

Not that I think it's a particularly important security concern. However, when
you are dealing with security concerns, the fact that you can't make up a
situation that sounds bad enough doesn't mean that nobody else can't.

Update: sorry for the wording of the last sentence (non-native speaker here).
I'll be glad if someone can correct it, because I can't figure out how to
construct it to sound well.

------
timr
Reading Java people's complaints about the deficiencies in their fifty
different build tools makes me want to force them all to use Make.

~~~
angersock
They typically spell it "ant".

~~~
ExpiredLink
That's the main problem people have with Maven. They try to use it like
make/Ant - and fail miserably.

~~~
VladRussian2
"fail miserably" would be fine. Unfortunately it is "live miserably".

------
hansjorg
> a pom.xml can only list a single source folder. If you have more than one
> (for whichever reason)

I agree that this example demonstrates that the Maven model is broken, but why
would you structure your project like this rather than using another module or
a submodule?

Maybe it's just lack of experience, but I highly prefer the rigidity of Maven
projects compared to some of the messes that more expressive build systems
allow.

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

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

~~~
eropple
_> 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.)

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

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

------
chopin
I am not very experienced in using Maven, but the biggest problem I have with
it is, that it is hard to tell (at least for my level of experience) from
where dependencies are pulled. Is it my local mirror, is it something on a
central nexus in the company or is it totally from outside?

Build reproducibility, which the author mentions is another issue. When I
scrub the local mirror, the outcome can be completely different. Previously
builds where working fine, when I scrub, everything breaks. This is mainly due
to non-local dependencies which had been cached locally, but not replaced by
most recent versions.

Another suspicion I have is that most build scripts are slapped together by
googling until it works. Which of course is prone to being fragile (not to
mention legal issues because it is opaque from where all stuff is pulled).

~~~
fs111
Never, ever, ever add any repositories to your pom.xml. Never. Have one
central repo (nexus, artifactory, whatever) for your organization and make it
a mirror of all others via settings.xml, not in the pom. This adds a lot to
build stability and reproducibility.

------
tomohawk
Switched to buildr ([http://buildr.apache.org/](http://buildr.apache.org/))
years ago. So much better than maven.

~~~
stephen
+1 for buildr. It admittedly takes awhile to learn the DSL, but it seems like
all of these DSL build tools take awhile to learn.

(I think that was one really nice thing about Ant--you could scan their
manual/list of tasks and understand it very quickly.)

It seems a little odd using Ruby to build Java projects, but ironically I
actually prefer that over Groovy.

This is horrible for me to say, but I'd like Groovy to gracefully go away--it
lost the Java.next race (they were stubborn about dynamic typing for way too
long) and I feel the only reason it's still around are for the admittedly nice
frameworks it sprouted: Grails and Gradle.

The language itself is "meh", IMO.

...although it bothers me to no end that a dynamic language like Groovy had
compile-time AST translation way before other (similarly mainstream) static
languages like Scala.

Anyway. Gradle's momentum is impressive. Perhaps I can unlearn my Groovy bias.

------
richardw
He and others continue discussion here, with some depth.

[https://plus.google.com/113945685385052458154/posts/7LHoGXQd...](https://plus.google.com/113945685385052458154/posts/7LHoGXQdkri)

------
hansgru
> Maven is broken by design

It might be, but it still has it's merits. It was one of the first, and many
other improved tools can't work without it's repositories.

I still like the IDE support for MVN: e.g. IntelliJ draws a nice dependency
diagram that I find useful, even if I don't use Maven for something else in a
project.

Maybe it's biggest mistake was that dependencies are global by default, and
not local (like Node's NPM). If the dependency structure would have been local
to a project, than many of the pain points I encountered with MVN in the past
wouldn't have even existed.

~~~
mercurial
> Maybe it's biggest mistake was that dependencies are global by default, and
> not local (like Node's NPM). If the dependency structure would have been
> local to a project, than many of the pain points I encountered with MVN in
> the past wouldn't have even existed.

I don't understand the local vs global dependency thing. What does NPM do
differently from Maven?

~~~
delluminatus
NPM stores dependencies in a node_modules folder _within the project
directory_ , i.e. "locally." It does have a command-line flag to store
something globally, though -- useful for dependencies with executables.

I'm not a Java developer but it sounds like Maven stores all its dependencies
globally (like in /usr/share/java). I'm not sure why that would be a "pain
point" except making it hard to do different versions of the same library.

~~~
mercurial
Maven stores dependencies in ~/.m2/repository (so "globally" per user).
However, it can and does store parallel versions of the same library without
issue. It's not much of an issue unless you need to copy your source folder
elsewhere, in which case you either need to copy your .m2 (with stuff from all
your various projects) or wait until maven re-downloads everything.

------
ssfsx17
What is inherently virtuous about a build tool being pure-declarative and
having no imperative impurities?

~~~
andrewaylett
Any tool can get hold of the full state of how to build the project, then
interpret it itself, rather than having to work out what the imperative code
is trying to achieve.

------
Randgalt
FYI - [http://tesla.io/tesla/index.html](http://tesla.io/tesla/index.html)

------
dschiptsov
Just maven or the whole Java philosophy of avoiding any
understanding/researching/thinking before beginning to pile it up inside an
IDE?)

~~~
cuillevel3
I don't think there is an actual maven IDE. You normally use it from the
command line, since it's integration into IDEs is serverly (eclipse...)
lacking.

~~~
chii
If you use Intellij IDEA, their maven integration is top notch. light years
ahead of eclipse.

~~~
chinpokomon
I concur.

I'm the only developer in my shop using IntelliJ. Everyone else uses NetBeans.
Whenever someone asks me how to setup NetBeans to handle builds as easily as I
do, I have to shrug. Simple things, like switching to offline mode or turning
off tests is a chore for NetBeans, but it is just a simple button click for
me. If I want to target a specific build profile, I check a check box.

As I'm the one who maintains the build, configuring pom.xml files and setting
up modules, I can see how it can become difficult for someone who doesn't have
the experience I do. OTOH, I've yet to find a problem that stumps me when I'm
doing things the Maven way, and I rather enjoy the flexibility and power it
provides me. Once I've got the basics in place, maintaining the system is
almost trivial.

