
Why Everyone Eventually Hates or Leaves Maven - dfj225
http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html
======
dasil003
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 back to the late 80s, I
realized that things I had learned 10, 20 years ago from the UNIX world were
still relevant today. I committed myself to getting serious about vim because
I want to optimize for A) learning many programming languages and B) not using
verbose Java-like languages that require IDEs for the all the boilerplate and
rote refactoring.

While this kind of toolset will never provide quite the bang for the buck of a
contextual IDE in a specific language, it's a phenomenal hedge against all the
career risks I face in terms of Ruby becoming irrelevant, the web becoming
irrelevant, Apple nerfing OS X, or any other probable sea change. No matter
what happens I feel like vim + bash will bring me an immediate level of
productivity in any new task I face, even if I start flattening out before I
reach the Eclipse or Visual Studio level of wizardry, I don't expect any one
thing to last long enough in this industry for such optimizations to pay off.

~~~
laureny
> 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 screwdriver over a drill.

~~~
gizmo686
My understanding of dasil003's point is that it is not a complaint about IDEs,
but rather about languages that are designed in such a way as to require IDEs.
For example, in Java, if you want to sort a List by a given field (using the
Native Collections.sort method), you would need to do something like:

Collections.sort(myList, new new Comparator<E>() { public int compare(E o1, E
o2) { return 01.val-02.val } }

(You could also make your class implement Comparable, but then you need to own
the class, have only one ordering used in the entire program, not mind making
the ordering a property of the class).

If you are in an IDE, then writing all that out is not to bad because of auto
complete. If you are stuck in a plain-text editor, you would much prefer
something like: Collections.sort(myList, lambda<E->int> x->x.val);

Java 8 does incluse lambda's, so maybe this particlar case has been solved.
But languages with a strong CLI pressense in the community tend to need alot
less IDE than languages with a strong IDE pressense in the community.

~~~
gchpaco
Another way of looking at this is how much code you have to read. This is one
of the reasons I hate wizard generated code in a way that I don't hate
InterfaceBuilder or similar serialized object trees. If I'm gonna have to read
the code eventually, the fact that your IDE makes it easy to draw a button is
cold comfort to me when it takes 100 lines of cryptic C to do it (actually
pretty common in early Windows programs or Xaw hacks, but mercifully
diminished in frequency in these more enlightened days).

Code generation can cause people to neglect library design; the reason why the
MFC wizards spat out volumes of code instead of calling a library method is
because you might need to rewrite some or all of that. You are not expected to
modify InterfaceBuilder output, nor should you have to any more than you would
have to regularly rewrite bits of Xlib to customize them appropriately.

------
ap22213
It's a trade-off, right? As most things in software are.

Recently, I inherited a project that had 10,000s of lines of ant scripts.
Resource constrained, I didn't have anyone to maintain that build process. So,
I took a few hours and converted those projects to several hundred lines of
maven 'scripts'. Now, it works way better than the previous system, because
now I can have a person focused on coding features, rather than maintaining
process.

Maven was what I knew at the time; and, it fit well enough. Maybe Grails is
the right answer, though. Or, something else.

Anyway, ultimately, it comes down to what trade-offs we make and what things
we prioritize with our limited knowledge that we have available. And, that is
the art of software development.

~~~
doktrin
> maybe grails is the right answer

The poster probably means gradle. I am not pointing this out to be pedantic,
but because it's not a given that every reader will know their way around the
universe of build tools.

~~~
ap22213
Oops - typo. Yeah what he said

------
mcherm
I don't hate Maven, and I haven't left it yet.

But he is absolutely correct about the key observation: a basic tool with
"plugins" is simply NOT the way to create a build tool. 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.

~~~
jbrackett
You should take a look at <http://www.gradle.org/> if you haven't already. I
worked on an ant project and decided we needed to convert to a better build
system. I started down the path of Maven, but Gradle changed my mind because
of the conciseness.

It uses the groovy language so hopefully it doesn't fall into the same trap as
described in the post.

~~~
meddlepal
Gradle has given me a lot of headaches for small projects. I keep going back
to it now and then and run into performance issues with it where builds that
take 10 seconds in Maven take 10 min in Gradle.

It's something about the dependency resolution mechanism. Something is broken,
but I haven't been able to pin-point it yet.

It's frustrating because I love Groovy. I write a lot of Groovy and I'd love
to use a Groovy-based build tool, but I can't justify wasting a lot of time on
Gradle when I know how to do what I need to do in Maven.

~~~
msgilligan
I've used Gradle on a handful of small projects and am very surprised that
you're seeing an order of magnitude difference between a Maven build and a
Gradle one. Can you provide a little more detail about what the script was
doing for 10 minutes?

~~~
meddlepal
Last time I used it which was right around when 1.3 was released I turned on
debug logging while the project built so I could see what was causing the
issues. It was hanging long periods of time around a task I had to make a fat
jar. If I remember correctly it was having some real trouble with locks on Ivy
caches... I tried clearing out the Gradle caches and that did not resolve the
problem. Since that was a small project I was able to replace the build file
with a POM and assembly descriptor be done with it.

If I get some more time to play around I might go back and try and collect
some more info for a bug report... I have had this issue since the late Gradle
betas each time I go back to using Gradle I hope the problem is resolved.

~~~
msgilligan
Well, 1.4 claims to have improvements to dependency resolution, so soon you
should be able to take another kick at the football soon. I'm growing to like
Gradle more and more and haven't seen any problems like this. My major desire
is for more/better plugins, but I do think this will become less of an issue.
(I'm even hoping to write 1 or 2)

I should also mention that GVMTool is worth checking out if you're on a UNIX-
based system. An easy way to install and switch between versions of Gradle and
other tools: <http://gvmtool.net>

------
berlinbrown
If you look at the practical real-world environments, Maven beats out most
other approaches for large projects. I think you have three or four different
build setups. I prefer Maven for large projects and Ant for small projects. Up
votes for the person that makes working, maintainable, easy to read and modify
maven scripts. (not you Spring or JBoss).

Anyway, you have three levels of builds.

\- Complex Perl scripts, bash/unix scripts : these people are insane and
generally have degrees in physics and mathematics. They write scripts that are
unreadable, can't modify, are cryptic and I imagine that that the authors
can't read them. I sometimes see these in old Linux programs.

\- Complex Make, Autoconf, bash/unix scripts : A little better than the perl
build scripts but still a complex because you have to understand each command
used. I am not fan and never was a C/C++ developer. I guess these are still
used in the non-Java world. I am looking at you 'OpenJDK/Sun JDK'

\- Complex Ant scripts : These aren't bad, easy read, a little bit difficult
to maintain over time. I think most developers prefer Maven but don't mind an
Ant script if the project is small

\- Maven Scripts : I think people use maven because not much else exists. And
the problem of compiling code is not that serious as the actual application
development.

~~~
chrismaeda
I've had the opposite experience. I've converted 2-3 complex build systems
implemented in different flavors of make to ant. It's tedious but it's doable.
And once you get to ant, it's a lot easier to maintain compared to make.

I looked at maven a couple time but could never figure out how to convert a
make-based build to maven because there is always a bunch of weird hacks
lurking in the makefile. However, I do see how maven would be fine for a new
project.

~~~
cbsmith
Honestly, make based projects are generally infinitely easier to parse and
manipulate than Maven. Maven helps by providing a fixed organizational
structure that is immediately familiar (and this is the advantage of being
opinionated that I do think the article understates), but you can keep the
structure and use make and be much better for it.

------
jamieb
"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 do it. You may
think you need to do it, you probably don't. Maybe what you need is a more
powerful deployment system, or something that takes over after your
java/scala/whatever is built.

If you're building perl, C, C++, sure, maven isn't going to do it for you. If
you're building java, you're sorted.

My favorite is when this sequence happens (I have seen it first hand):

    
    
      1. Maven is this external system that we have no control over.
      2. We will write our own system that will be awesome.
      3. Wow, look, every project uses our Build System!
      4. Oh, look, someone on project X changed B.S. and now Projects A-N don't work!
      5. We will lock down B.S. so only the one person who wrote it can change it!
      6. ...
      7. B.S. is this internal system that we have no control over!
      8. ...
      9. Can we add support for merging war files?
      10. No that'll take weeks, and Bob isn't available anyway.
    

I'm sure you can fuck that up just as well using Ruby. Go for it.

I work in a java shop currently. There's got to be a hundred of us. Every
single one uses an IDE.

When I use maven, my IDE just works. eclipse, intellij, netbeans all support
maven. Want to put a bunch of files in a common war to share? maven has a
merge-war plugin and intellij and eclipse know what it means: they both build
projects that copy the files just like maven would do. Better yet, as you edit
those files, no matter where they are, both eclipse and intellij update the
files in the deploy target and they are available when you refresh your
browser. There is a huge amount of investment in making this stuff work. This
is convention over configuration.

No tool can do this with Ant (or Ruby) unless it _runs_ the Ant and the Ruby,
and then you've side stepped the IDE and reduced them to dumb text editors.
With an Ant project, the IDE can't know that when I edit file A, it is
transmogrified into file Z. (If it could, it could solve the halting problem).
With Maven, the IDE implements _convention_ , and so it know that File A is
compiled to File B and then must be copied to location Z because its part of a
merged war. Add JRebel to the equation and pretty much any change to the code
is immediately runnable. Its dangerously easy to spike away instead of writing
tests!

~~~
gchpaco
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 Java
class so you can refer to it easily).

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

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

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

\- 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, json > 1.4.2, and many other worse
things.

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

\- deployment.

From bitter personal experience it is possible to get so wrapped up in this
that you think you have achieved something amazing when you finally finish,
when it could have been done in a few hours in make or rake.

"Oh, but you can integrate it with your IDE!" The only thing your IDE actually
needs to get from the Maven POM is to understand where your source code is,
what you depend on and where it is, and how to run your tests. Everything else
they do with command line calls, _just like it was Ant_.

~~~
timv
You can add pretty much anything to do with CORBA to your list. Yes there are
plugins for it, but they only work in the most trivial of cases.

The original article was helpful to clarifying for me why I have such a low
opinion of maven - the project I was working on when Maven came out was a
large complex codebase and we'd built lots of interesting things into our Ant
build files. I could not work out how to ever do those sorts of things in
Maven.

~~~
cbsmith
Badly written programs are far from an inevitable outcome with contextual
tools. That is more a symptom of Maven's choice of a rather narrow context
that has limited its appeal (that and all the ways it sucks ;-).

------
tomlu
I've worked on two build systems (and used many more). The conclusion I have
arrived at is you don't want a declarative-only system (like Ant). They can be
convenient but as your needs grow more complex they start becoming a
hindrance.

Instead, you want general purpose language that builds the build dag using the
build system as a library. This gets you control and customisability for free,
and you can still get reuse through code libraries.

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

~~~
jomohke
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?

~~~
jamieb
That's my favorite. "Maven is taking too long. It must be shit. I'll write my
own!"

Question: Maven is taking too long and downloading plugins and dependencies
everytime. What should I do?

Answer:

1\. Its shit! Write my own!

2\. Well, that seem suboptimal. Would the smart people who wrote it have made
it download all this stuff everytime it builds? Surely that is wrong. Maybe I
could google that?

------
wellpast
I wholeheartedly disagree with this post, though I do like his conceptual
framework of composable and contextual abstractions.

I've worked on countless Maven builds and have done everything under the sun.
Maven's plugin system allows you to ultimately achieve whatever you need out
of your build--in the 10% case that you have a need that isn't already covered
by the varied plethora of plugins out there. You can even call out to Ant
using the antrun plugin.

I've found so much simplicity, reliability, continued payoff in my use of
Maven. I've heard complaints but usually from people that refuse to understand
how it functions declaratively.

Declarative systems like Maven ask that you learn something first, and then
reward you infinitely if you do; imperative systems let you do something
immediately without learning a model, but then make you infinitely pay for it.

~~~
frugalmail
brilliant summary.

------
Corrado
I think the article title is a big provocative and is drawing attention away
from the main point: composable tools are better (in the long run) than
contextual ones. Maven (and Ant) are contextual tools and they give a lot of
benefits early on. Extending their use beyond simple things tends to become
difficult and makes very messy build/deploy code.

Tools like Rake and Gradle (and Buildr) are more like thin wrappers on a
turing complete language and are able to stretch and bend to fit the problem.
Sure, that makes them harder to get started with, but it provides much more
runway when the build gets complicated.

I've used Maven in the past on some projects and it starts off very nicely.
However, without fail, I end up with some part of the build that doesn't work
quite right. Or throws unresolvable errors. Or just fails, some of the time. I
guess I (and everyone I've ever worked with) sucks at Maven and just can't
make it work. If so, that tells me much more about Maven than my team's
abilities.

P.S. I (mostly) blame XML for my Mavin chagrin. Over the years I've grown to
hate XML and everything associated with it. It should burn in a fiery pit of
lava. But that's just me. :)

------
typicalrunt
Oh wow. I just raged at my manager for exactly this type of problem.

I'm not sure if it's due to someone's lack of technical ability, or if they
get distracted by other externalities, but we always tend towards something
that seems really simple at first but instead incurs a lot of technical and
process debt later on.

Brilliant read.

~~~
epochwolf
My experience is this is caused by a lack of refactoring/ rewriting code when
it can no longer support easily modification into the desired functionality.

------
3amOpsGuy
I enjoyed the article but I feel it overlooks one of the biggest reasons to
use something like maven:

It gives us the language to efficiently reason about and discuss build
concepts with colleagues.

This is a big thing, think about the most recent new starter situation you
experienced, about how communication of these common build tasks was
expressed. Chances are if it was with a more composable tool, the discussions
were fairly detailed, the words 'just like' frequently appeared. If it was
with a more rigid tool, the conversation would have been in terms that tool
commonly defines.

------
dustingetz
The compromise of composabilty is that if you don't already understand the
problem domain, you don't know how to structure your code. Frameworks are
brilliant for paving a golden path for us to follow - we get to reuse someone
elses knowledge and experience, codified into the framework.

A great example is the present state of browser development t. Google
"backbone sucks site:news.ycombinator.com" and you find tons of comments from
people who struggle with backbone - a supercomposable _library_ , not a
framework by design.

Composabilty pays off huge in the long, but you need experienced leadership to
wield it.

There's also a happy medium in things like Play Framework, a functional scala
framework but designed almost as a collection of composable libraries so you
can lean on Plays opinions for most things but since it is designed to be
composable (compare to "pluggable", or "extensible") so you can swap different
pieces out if you like. That is my experience, at least.

------
tomohawk
I've found buildr (<http://buildr.apache.org>) to be a great replacement for
maven. It provides many of the capabilities that maven does, but it's also got
all of the power of ruby/rake for taking care of those things that come up
that the plugin/declarative approach just cannot handle reasonably. We
converted our maven builds in a day and never looked back.

------
andrewem
Doug McIlroy's solution is genius, and I hesitate to try to improve it, but it
seems to me that if you reverse the order of the 'tr' commands, then you can
slightly simplify the one that turns non-word characters into newlines, like
so:

tr A-Z a-z | tr -cs a-z '\n' | ...

Since you first turn upper-case characters into lower-case ones, you then get
to replace only things that aren't in a-z with newlines, rather than things
that aren't in A-Za-z. It saves a whopping three characters!

------
edwinnathaniel
How about Maven 3 and Groovy DSL?

[http://www.mail-
archive.com/users@maven.apache.org/msg126205...](http://www.mail-
archive.com/users@maven.apache.org/msg126205.html)

At least the people behind Maven took notice that there is a problem and
working on something.

~~~
monksy
Shhh you'll interrupt the maven hate circle jerk.. We can't have that.

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

------
nichols
better link: [http://kent.spillner.org/blog/work/2009/11/14/java-build-
too...](http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html)

After about a year of experience with Maven, I find that:

* The "surefire" plugin is named ironically. The build often fails without a message about what unit test failed.

* Maven is extremely slow. Eclipse builds the source in 30 seconds max; Maven takes 5 minutes.

* Maven's output is extremely verbose, but if anything goes wrong, it "helpfully" tells you to rerun it with -X -e to get the actual error message and stack trace. You can run it with -X -e all the time if you want, but I think it generates so much output that it actually slows down the build. Yes, really.

* There are a lot of things you just CANNOT DO in Maven. One example is bundling a Maven plugin together with the rest of your Maven source and use that same plugin elsewhere in the project. It fails during the early phases of the default lifecycle because the plugin isn't installed yet. But only by getting to the later phases of the lifecycle can you install the plugin. But you can't do that because the early phases fail. An infinite cycle of despair is right.

* Even the most trivial project takes a few screenfuls of XML to set up in Maven.

* Maven's dependency management is poor, too. If you have some library A that pulls in B, and another library C that pulls in a slightly different version of B, you can get misbuilds. It's your job to identify and fix these problems. They will show up at runtime. And let's not even talk about SNAPSHOT and how horribly that can go wrong.

* Maven is also known for pulling in tons of unnecessary dependencies. But hey, you don't mind 50 more megabytes of jars on your CLASSPATH, do you?

I was honestly expecting the article to address some of these points, instead
of vague philosophical ramblings. Seriously, Maven is horrible. This article
gives you no inkling of just how bad it is.

------
pjungwir
I was surprised to see him include ant with maven. I always thought of ant as
more a set of composable tools than a maven-like context, and for that reason
I preferred it.

That said, I recently had to use ant after many years doing Ruby, and I was
surprised to find how many old annoyances were still there, like
scarce/painful support for conditional execution. I wanted a task to `cp` in
development and `scp/rsync` in production, and I wound up having to duplicate
a lot of code. Also I'd have thought that someone would have added the copy
task's filter support to scp by now. (If anyone knows a clean way to do any of
this, I'd love to hear it.)

~~~
gchpaco
Ant and a lot of the build tools that grew up around Ant don't support what
make calls pattern rules very well. It's a lot like the difference between
using Prolog and C to do the same task. A good example of how this is painful
is to try to imagine how difficult it would be to handle the dependencies
between various Java source files automatically if <javac> didn't do it for
you.

To pick an SNMP related example, since I've done a bunch of that, suppose you
have a MIB for your organization (using a hacked private OID that you haven't
told anybody about for development, because it's easy) and then a lot of other
MIBs that depend on that. And then one bright day you get your IETF approved
SNMP OID for your organization, and you need to retarget your MIBs to be under
that. It _could_ be as simple as changing the base MIB to the new, official,
OID and then letting your build tool rebuild the generated files in the
correct dependency order--but that's hard to do with Ant. Usually you'll just
rebuild all the generated files and then rebuild all the downstream code and
then ... It's not trivial in make but it's not especially difficult--make for
example has no real knowledge of C code, but with cc -M it doesn't need any.

------
lifeisstillgood
I completely agree with the thrust of this - I see frameworks over
composability everywhere these days and it makes my head spin.

However we do not yet seem to plug http in the same way we pipe command lines.
Something seems to be missing,

------
mathattack
I love the Access analogy. It burned me quite a few times in prior lives, when
every project started with, "Let's build an access database." Ultimately it's
a tradeoff in abstraction and usability.

~~~
chii
i actually doubt the problems with access are really that bad - sure you
outgrow it eventually, but you'd be surprised at what its capable of.

Often the real underlying cause is that a business owner with little to no
programming knowledge makes something which works ok, but is architectually
wrong. For example, bad table structure/relationships. Or after a while, they
want to 'put their app online', and asks a poor intern to convert it.

~~~
mathattack
This is true too. Sometimes screens are designed by people who don't think in
terms of relational tables, and then the data eventually gets messed up.

------
Uchikoma
After 3 years of SBT for Scala development, which plainly does not work, b/c
SBT developers do not like simplicity (the irony!) and are more interested in
doing cool stuff than stuff that works, I'm only a small push away from going
back to Maven/Zinc, that favors 'just works and you can't shoot yourself in
the knee with an arrow' over 'powerful'.

~~~
lmm
Do it. I've been building Scala with maven for years; it just works.

------
politician
The usual backstory is that the old thing was cobbled together over a period
of time while the requirements shifted about underneath it. The new thing
appears to be "more awesome++" because the requirements are fixed at that
point in time. Inevitably, the new thing is forced to cope with changing
requirements and the cycle repeats.

------
vorg
What are the biggest differences between Rake, Gradle, and Leiningen? All 3
allow their respective language (i.e. Ruby, Groovy, Clojure) to be used within
the build script, but besides the pros/cons and popularity of those languages,
what are the differences between the build tools themselves?

------
Uchikoma
Maven just works and if you stay within it's intent, it does it's job.

We use Maven with Bamboo for continuous integration and it just works. We play
with the idea to move to Gradle b/c it's more powerful, but the effort is non
trivial and the real benefits - beside the 'but it's programmable' - not
clear.

~~~
lmm
"It's programmable" is a downside here. You do not want your build system to
be turing-complete; keep it simple, and Maven enforces that.

------
hakaaaaak
It's not Maven. It's Java and XML. They both end up involving much more
overhead than Ruby/Rake.

~~~
huherto
IMHO, it is XML.

~~~
frugalmail
XML is a great language since it has the power of schemas and DTDs. It makes
it easy to validate the data you expect in each of the fields.

And fuck am I tired of hearing about how saving 10% of your keystrokes during
authorship is such a great thing. Most of the time spent on software in in
maintenance, so you want better _readability_ than terseness. coffeescript,
yaml, etc... are far inferior solutions for most of the uses they get put
towards.

~~~
lmm
>XML is a great language since it has the power of schemas and DTDs. It makes
it easy to validate the data you expect in each of the fields.

Quite the opposite. XML Schema is an awful mess - it's not even representable
in XML; it's not a good language for expressing validation constraints, it's
neither simple enough to be easy, nor powerful enough to express all your
requirements. And the need to support schema leads to DTDs and namespaces,
which are responsible for most of the screwups of using XML in the real world.

If XML were just tags, parsers didn't try to connect to the internet to
validate everything, and tools didn't bother with namespaces, it would be
usable enough that we probably wouldn't have needed to invent JSON.

------
sabalaba
The author didn't provide any background about the original Knuth "Literate
Programming" paper and subsequent review by McIllroy. Knuth was using that
code to demonstrate Literate Programming style. While the quote / anecdote was
taken a bit out of context, I agree with the fundamental idea: code reuse.

[1] <http://en.wikipedia.org/wiki/Literate_programming>

[2] "Literate Programming"
<http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf>

------
huherto
I totally agree with the article. I love somethings about maven but XML is a
pain to work on.

I am thinking that a build system can be built on top of Java. But Java for
shell scripting has some drawbacks that can be alleviated. I am working on
these little tool to use regular java for shell scripting, it is auto
compilable and it has better abstractions for file manipulation.
<https://github.com/huherto/jashi>

~~~
_pdeschen
Hum? Groovy?

------
6ren
I now use bash instead of ant. It's really fast, makes sense, does whatever I
want.

But it has the lisp problem (and now ruby problem) of everyone making their
own tooling, without standardisation. (where a "standard" is procrustean: it
doesn't exactly fit any situation, but the situation is forced to fit it).
Pre-chasm innovators/early-adopters love it; everyone else hates it.

BTW: I don't think "contextual" is a very descriptive term ("composable" is
great though)

------
rjzzleep
i'm really wondering, why xml is burried so deep down in the comments. I would
argue that Maven is just reflecting a methodology implied by xml, some like
it, but well...

this: <http://www.defmacro.org/ramblings/lisp.html>

even though having completely different intentions, shows the parallels quite
well, imho

~~~
andrewflnr
I think most of it is verbosity, both that inherent in XML and extra caused by
crummy schemas, that makes people hate XML. It turned into an "enterprise"
thing, with all the philosophy that entails.

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

------
amalag
I can't understand the Maven hate. People prefer their own half baked ant
tasks which don't handle dependencies? IMHO Maven takes some getting used to,
but it brings a lot to the table and can make the build process very
repeatable and extensible.

------
jebblue
Good article. I like the idea of what Maven tries to achieve but I prefer
monkeying with ant because I can get things done. If Maven or its successor
ever gets to where things can't get into a mucked up state; I'm in.

~~~
frugalmail
strange, by default maven is much more strict about things, so it's hard to
muck up. Perhaps you weren't creating the maven project in the format it wants
you to create it in (which IMO, is a good one). Have you tried creating new
projects with

mvn archetype:generate ?

~~~
jebblue
>> Generates a new project from an archetype, or updated the actual project if
using a partial archetype. If the project is fully generated, it is generated
in a directory corresponding to its artifactId. If the project is updated with
a partial archetype, it is done in the current directory.

I don't recall trying that however, sorry that whole description from the link
you provided, it just doesn't make sense to me. In general, when I try to use
Maven, Eclipse ends up complaining. Then I fix it so Eclipse is happy then
Maven complains.

Maybe the answer for me would really just be get the Maven and the Eclipse
people to agree on how to create and manage projects with the Eclipse wizards.

------
Niten
> Donald Knuth was asked to write a program to solve this text handling
> problem: read a file of text, determine the n most frequently used words,
> and print out a sorted list of those words along with their frequencies. He
> wrote a program consisting of more than ten pages of Pascal, designing (and
> documenting) a new algorithm along the way. Then, Doug McIlroy demonstrated
> a shell script that would easily fit within a Twitter post that solved the
> problem more simply, elegantly, and understandably (if you understand shell
> commands)

Fine anecdote, but anyone want to take a wager as to the relative time and
space complexity of the two solutions? I imagine this is sort of comparing
apples and oranges.

~~~
nisa
I guess it is part of the idea that you can ignore that. The shell script is
_good enough_ for 80% (I made this up) of use cases. Knuth's solution is
probably faster and requires less resources but if I want to reverse the
filter order or change something else You are way faster using the shell
script. It's also probably not so difficult to look up how each of these tools
work internally to make an informed guess on time and space complexity. This
will come in handy if you use the tools next time. And unix tools aren't so
slow. I wrote some C++ code using mmap() files to filter out some chars. It
was only marginally faster than some pipe using tr.

~~~
Niten
To be more precise, I think the biggest problem with this anecdote is the
notion that this guy somehow "one-upped" Knuth by coming up with a pragmatic
rather than a theroetically optimal solution. Knuth is a mathematician after
all, and if someone asks him to write a program they're implicitly asking for
a mathematical result, not an unremarkable engineering tool.

So no, taking this anecdote at face value, this guy didn't "one-up" Knuth;
they were effectively answering two different questions. There is more to
computer science than finding the simplest shell script to solve the 80% case.

------
deltasquared
For me personally, leinigin is why I don't use Maven that much ^_-

Also, you would be surprised just how much "Java" programming you can do with
a decent XML editor. IDE's are overrated.

------
commentator
I like this one:

What has Maven ever done for us? <http://www.wakaleo.com/blog/what-has-maven-
ever-done-for-us>

:-)

------
laureny
It's hard to be wrong when you claim that you either eventually hate or stop
using a software tool.

I can't think of many tools that escape this simple truth.

~~~
lmm
Ironically enough Maven is quite possibly the only exception in my own
experience.

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

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

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

~~~
benjaminwootton
It's two lines...

mvn archetype:generate mvn package

------
moneypenny
TLDR: Maven makes hard things easy and easy things really f __ __ __hard.

~~~
gchpaco
Maven isn't even good at making hard things easy. Trivial things are easy and
anything else will take a day of head scratching, _minimum_.

~~~
chii
what would you consider something as trivial, and what is hard?

~~~
gchpaco
Building java libraries isn't really all that difficult. Not is packaging
them. Damned if it doesn't take 30 lines of XML to do it in maven, but these
kinds of see-spot-run situations are pretty easy.

Extremely difficult in maven and five minutes work in make or ant is things
like "running LaTeX to generate a PDF of some of your documentation, because
it is math laden and HTML isn't suitable". This is not theoretical; I had to
do this at the place that was using maven and we depended on some semi-obscure
mathematical formalisms like the stable distribution.

Intermediate between these two is driving things with maven plugins, which is
either easy (because you're doing something trivial) or fiendishly difficult
because the debugging output is terrible, the docs are worse and the only
thing left to you is to Use The Source, Luke. Every nontrivial maven plugin
I've ever used has tripped this at some point, be it loading config files,
including the dependencies, or something else.

~~~
rossjudson
Or you could use org.codehaus.mojo:latex-maven-plugin, stick your latex and
graphics in src/main/latex/<doc>, and watch it 'just work', like I do.

I agree that not every maven plugin does exactly what you want it to, but a
lot of them get pretty damn close, and as the authors iterate them, they gain
a lot of flexibility.

~~~
moneypenny
I don't have too many issues getting latex running either, but I do mostly
agree, despite my humorous aside. If I had a quid for every extra hour that
Maven added to my work above and beyond the coding, I could take you all to
lunch. Tools should at least attempt to get out of the way. Maven is a Swiss-
army knife with a blade as the handle.

------
martinced
I managed to do my entire Java career by dodging Maven but I'm now learning
Clojure and I really like the language but, sadly, I'm not fluent enough in
Clojure to do everything "by hand" so I'm using Leiningen...

And Leiningen uses Maven under the hood :-/

~~~
weavejester
Leiningen doesn't use Maven under the hood. It understands the Maven
repository format, and imports a few classes from Maven for searching Maven
repos, but that's pretty much it.

