Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Friday, May 21, 2004

Moving Away from Maven

I've gotten some comments asking why I'm moving away from Maven.

I started to use Maven initially as part of the HiveMind experiment. Fundamentally, I liked two specific features:

Maven does those two things pretty well, though the documentation part has a large number of bugs that makes keeping the documentation up-to-date problematic.

Anyway, measured by my Four Principals, Maven falls shorts:

  • Simplicity - this isn't even on the horizon in Maven-land. If you deviate even a tiny bit from Maven's one-true-path, you are lost! The complexity of plugins, class-loaders, XML documents that are Jelly programs in disguise, lack of documentation, etc., etc. means that doing something trivial can take hours of guesswork. Some parts of this "release candidate" have obviously not even been given a cursory test. Certainly the internals of most plugins are a maze of Ant, Jelly, properties and such, seemingly without end.

    This could be somewhat addressed by documentation, but there is a pitiful amount and what there is, is out of date. Understanding multi-project (the whole point of Maven you would think) is a total challenge, addressed only by endless experimentation.

  • Consistency - I guess this is hard to guage; do you write your own plugin? Write ad-hoc Jelly script? Write and use an Ant task?
  • Efficiency - Maven is sluggish, chews memory, tends to repeat operations needlessly. I could comment on the volume of downloads that occur (for plugins, for libraries the plugins depend on) but that actually isn't an issue, after you run Maven the first time. However, for HiveMind, I've taken to leaving the room while I perform my dist build ... and it's only two small projects.

    One concrete example: when using Maven, I could only get my unit tests to work by turning fork on. With Ant, I'm able to run the unit tests without forking. That's a huge difference.

  • Feedback - Can you say "NullPointerException"?

What I've accomplished in two days using Ant 1.6 will serve me well for HiveMind and for Tapestry ... and beyond. I think we'll be able to get a significant amount of Maven's functionality in a small, finite, understandable package, and be able to use it on the vast majority of pure Java projects.

For example, Here's the build.xml for the framework:

<project name="HiveMind Framework" default="jar">

	<property name="jar.name" value="hivemind"/>
	<property name="javadoc.package" value="org.apache.hivemind.*"/>

	<property name="root.dir" value=".."/>
	<import file="${root.dir}/common/jar-module.xml"/>
	<import file="${common.dir}/javacc.xml"/>								
	<target name="compile">
		<ibiblio-dependency jar="commons-logging-1.0.3.jar" group-id="commons-logging"/>
		<ibiblio-dependency jar="javassist-2.6.jar" group-id="jboss"/>
		<ibiblio-dependency jar="werkz-1.0-beta-10.jar" group-id="werkz"/>
		<ibiblio-dependency jar="servletapi-2.3.jar" group-id="servletapi"/>				
		<ibiblio-dependency jar="oro-2.0.6.jar" group-id="oro"/>
		<ibiblio-dependency jar="log4j-1.2.7.jar" group-id="log4j"/>
		<ibiblio-dependency jar="easymock-1.1.jar" group-id="easymock" use="test"/>
		<run-javacc input="${javacc.src.dir}/SimpleDataLanguage.jj" package-path="org/apache/hivemind/sdl/parser"/>


And here's the the project.xml, project.properties, and maven.xml.

I hate to bash the Maven project ... but what I see in Maven is a good, simple, core idea that's spiralled down the wrong path by trying to be everything to everyone. That's a lesson I'm taking to heart as I build something that suits my needs better.


Brett Porter said...

Nice post Howard, although I think the Ant example is missing some things :)

I've rattled off a longer than intended response here: http://blogs.codehaus.org/people/brett/archives/000731_re_moving_away_from_maven.html

I hope you get a chance to read it and comment.

Russell said...

Where did you get the ibiblio-dependencies task? And how can the rest of us use it?

Howard said...

ibiblio-dependency is part of "HiveBuild" a collection of Ant 1.6.2 build files used by HiveMind and Tapestry (3.1) to build source. It's flexible and general purpose, but not documented.

Adam Fisk said...

I think the example of the ibiblio dependency is a perfect case of why Maven makes so much sense. Instead of my having to wade through pages of idiosyncratically linked ant build files in HiveMind, Maven standardizes the process. The point is not only to make it easier for the person who developes the code, although it certainly does that in many cases. The flip side of that coin is making it easier for other developers using your code. Granted, many people don't know Maven yet. With an equal understanding of ant and Maven, though, I'd argue that it's much simpler to jump on to a project and build it quickly and easily *and* to understand the build process. I'm still trying to figure out the HiveMind build process to build my own app, and it's not a process I'm looking forward to!

If you've ever used things like the Maven Eclipse plugin, the benefits become abundantly clear if you ask me. Saves people from writing the same ant code in slightly different ways all over the world!


Howard said...

I really, really, really tried hard to like Maven. I don't. It gets in my way, and is unpredictable from release to release. It was hindering my progress, more so than the effort of creating my own Ant scripts. Is Ant perfect? Far from it. But, for me at least, Maven is simply a worse option.

A truly object-oriented solution, where the "build files" or "description files" are, in objects (perhaps Groovy scripts or classes) would be wonderful. But I'm going to let someone else fight that battle.

The HiveBuild stuff is sufficient for building HiveMind and for building Tapestry and I'm not saying the world should run on it. Again, I can only fight so many fires.

Matt Moriarity said...

Thank you for your information about forking JUnit. I was having problems running my tests for a hivemind project and this solved my problems.

I tend to like maven, but maybe that's because I haven't had too many issues with it. Besides this one, most of my issues have been from my own stupidity.

Cedric said...

A word of warning about not forking a JVM for unit tests: this is a dangerous thing to do if you use statics in your tests (which you probably do because JUnit doesn't leave you much choice). Make sure you reinitialize them before each run.


Howard said...

Strange that this comment still gets a lot of views. Ant 1.6.2 has an option to fork once for an entire test suite ... I use that option.

In terms of statics though ... I almost never use those. What do you put in statics? Singletons. What is HiveMind for? Managing singletons. Use of HiveMind (or any other DI container) gets you away from suspect practices like relying on statics.

Anonymous said...

Odd, I've been using Maven for about a year now and I'm not finding it difficult to use or poorly performing, outside of the unit tests, which needs fixed.

It can easily handle an EAR project with a web project, EJBs, a myriad of dependencies and MANIFEST modifications for classpath entries...

Did you read the documentation at all?

Brian Topping said...

I'd advocate revisiting this decision with the advent of Maven2. I am just getting started with Tapestry, by way of Trails. I wouldn't even have bothered looking at Trails except that it uses M2. I just don't use Ant any more. What some call flexibility is spelled h-e-a-d-a-c-h-e for people that are using source code from framework dependencies as documentation to learn the framework. For instance, how do I generate IDEA project descriptors in Ant so I can generate the module descriptor and include it in my project as a dependency (instead of a jar with attached source)? Even in the extremely rare case it is in a particular build.xml, why should I even have to look for it?

It would be arrogant to judge your decision to stop using Maven, but Maven2 is a big improvement and I believe either version provides non-core developers of a given source tree a better chance of getting what they need out of it, being productive more quickly, and in the end, solidifying a stronger community around the product.

Howard said...

On Maven 2: I absolutely use it now every single day, at at least 90% of the time I like it. My only caveat is that for some things that I know how to do in Ant or Maven 1, I can't quite figure out how to do in Maven 2 ... there's a position where you go from using Maven 2 as a tool to appeasing it like a petty god. :-) But I do all my new work in Maven 2 without hesitation.

Toby said...

A good start would be a "hello-world" quickstart project for the Tapestry5 homepage...a ZIP file that includes everything you need. Without maven, nobody can try out Tapestry at present.