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.