Why not Maven

This blog post is in reply to a comment by Jason van Zyl on my previous post. It is written as a post since blogger does not allow me write syntax highlighting in comments.

Jason, you are probably right about me making assumptions about what Maven is, or at least what I think that it should be. But the fact is that, my main use of Maven is as a build tool!

And don't misunderstand me, I really like a lot of what Maven has brought to the community. The standardized repositories and the standardized project layouts being the main contributions.

I also like the fact of the one-click build, or one-click development environment setup, even though I don't think that these are an invention of Maven. I know that at least Joel Spolsky wrote about this years ago.

But what I don't like is that, whenever I want to do something that is not part of the standard Maven toolset, I have to invoke the Google Gods, and hope that someone has written a halfway decent plugin that does the work I want done. Most of the time, the plugin is OK and I end up using it. But, with every little thing I add, the project setup gets a lot more complicated and inconstant.

Below is an example of a configuration for generating documentation with asciidoc. I really think that the readability of the Maven part obscures what I want to do. And being obscure is one of the primary sins of programming and building in my book.

<!-- Generating a file with asciidoc and Maven -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.1.1</version>
    <configuration>
        <executable>asciidoc</executable>
    </configuration>
    <executions>
        <execution>
            <id>generate-deployment</id>
            <configuration>
                <commandlineArgs>
 --unsafe --out-file
${project.build.outputDirectory}/deployment.html
${project.build.directory}/deployment.txt
  </commandlineArgs>
            </configuration>
            <goals>
                <goal>exec</goal>
            </goals>
            <phase>compile</phase>
        </execution>
    </executions>
</plugin>

# Generating a file with asciidoc and Rake or Buildr
file ${project.build.outputDirectory}/deployment.html => 
 ${project.build.directory}/deployment.txt do
 sh "asciidoc --unsafe --out-file=#{to} #{from}"
end

The example above is just one, of many, that I have run into, during my years of dealing with build systems.

I took a look at Polyglot, and it is not the answer to my annoyances. My main annoyance is not the XML, it is that I cannot do simple things without having to resort to third party plugins that don't work the way I want them to. I want precision and Maven does not give me that. (Perhaps because I did not write it.)

I'm also sorry if I sounded like I thought it was easy to do what you are trying to do. I don't! I have tremendous admiration for your abilities and for what you are trying to do, but as I said in the blog post. I think you are wrong when trying to create a build system that does not include the ability to use programming abstractions. The abstractions lets me do simple thing easily.

Perhaps the problem is that Maven is trying to do to much. Perhaps there should be two parts, Maven-Project for generating nice project information about the status of a project, and Maven- Build for dealing with the part that is doing the building. In my opinion Maven-Build should be more like Rake and Buildr and less like what Maven is at the time of writing.

But you don't have to agree with me, you obviously have a different experience than I do. In the mean time I will continue to use Rake and Buildr, and continue to use the paved road that Maven has provided with its standardized repositories and layouts.

Maven, the new Elephant on the Block

Some of you may remember the article, by Bruce Tate, Don't Make Me Eat the Elephant Again.
It was an article about EJB, and Bruce was begging Sun not to make the same mistakes with EJB3 as they had done with EJB, and EJB2. They didn't, Spring came along as better alternative and forced EJB3 to become slimmer and better. If not for Spring, EJB3 would probably look very different from what it looks like today.
Well, guess what, there is a new elephant on the block and its name Maven2.

Just like EJB2, Maven2 was born out of something so unbearable that anything else was bliss. Jelly anyone!

But just as EJB was fundamentally flawed, so is Maven2. Build systems, even advanced ones like Maven is fundamentally about two things.

1. Check if something that something else depends on has changed
2. If so, do something.

That's it, that is what is important.
The checking may contain various sophisticated methods for detecting if files, subsets of files, all files, web pages, twitter feeds, etc, has changed, but that is really it.
And the doing can be anything, Copy files, commit files, build websites, run tests, generate code, launch missiles, whatever!
But the key to doing this efficiently is a programming language with easy access to system commands and the ability to create simple abstractions, with methods, variables, and objects. The language should also, preferably, be one without a lot of ceremony, like Ruby, Javascript or Python.
There are already build systems like this out there, Buildr, SCons, and Rake come to mind, but they do not have the momentum of Maven, so a merger between Maven and Buildr would be wonderful.

So, Jason, hear my plea, Don't make me eat the elephant again!