Tuesday, 6th of December 2005 I had the chance to attend Carlos Sanchez's presentation about Maven 2 at the LA JUG in El Segundo. I already played around with Maven 2 and therefore had a list of questions I tried to get answered. Especially I wanted to see if my concerns I expressed earlier in a Java.net blog where valid or not. Today I came to the conclusion that Maven 2 has some good ideas but I think that the Maven team threw out the baby with the batch water in some of the new features/restrictions and so I still prefer Maven 1 over Maven 2.

These is a list of the problems I have with Maven 2:

1. Properties cannot be set outside the POM
2. Any dependencies must be provided by repository (local or remote) and cannot be redirected to a directory within the project.
3. For now a project cannot reuse Jelly code from a Maven 1 project and so must convert that code into a Java based plugin.
4. The build hierarchy cannot be extended by the project (no pre or post goals) and the order of plugins executed within one build step is undefined.
5. The current Maven plugins use Java classes and the plugins downloaded do not include the source. The source archives of these plugins then do not include a build environment just only the Java source code.

1. Properties cannot be set outside of the POM

Many open-source projects use other applications to build, deploy or execute their application. Most of the time the project needs a path to this application like for example the JBoss deploy directory or the installer root directory. On the other hand the project cannot know the path to these directories and therefore does not want to include these directories into their version control system(VCS)..The only solution is that every user does set the path in a separate properties file like the build/project.properties file in Maven 1.
For me this is a must have requirements and I do not see another way around it.

2. Dependencies must be in the Repository

Not every open-source project has their archives deployed in the Maven repository or is able to run their own repository. Also sometimes the Maven repository is not up to date or cannot provide archives for other reasons. In that case an open-source project needs to add dependencies in their VCS and add the dependencies without the repository. Currently in Maven 2 a project can only ask the users to copy the archives in question to their local repository in order to make the build work.
I could accept that if Maven 2 would be able to have a project internal repository that can be made available through the VCS.

3. No Jelly in Maven 2

In Maven 2 one cannot inline or execute with a plugin any Jelly code one might have from a Maven 1 project. Even though that I do not like Jelly as a scripting language it really makes sense in conjunction with Ant because their XML code can be easily intertwined making it easy and fast. Maven 2 allows user to inline Ant and so I was wondering why not also Jelly.
This is a must have requirement for me.

4. Build Hierarchy

In Maven 1 it is easy to hook into the build hierarchy (defined by the plugins), extend the build hierarchy or do overwrite it (somewhat like in AOP) with what I need. Maven 2 does not allow me to do that anymore and so I am stuck with the build hierarchy. For example if I would have a code generation tool's output is the others code generation tool's input then I have a problem because I cannot define an order in that step. Whatever build hierarchy Maven 2 has there will be projects that do not fit in. As much as I agree that many developers misuse Maven 1 there are still valid exceptions out there that do require a more flexible build hierarchy especially when Maven 1 had this flexibility.
A tool must make the life of a developer easier and that is just the opposite.

5. Source of a Plugin

Having the Jelly script with the Plugin in Maven 1 as the one single feature that sold me to it. It helped me tremendously to understand Maven, was a great source of how to do it and an easy way to debug it. Now with Maven 2 the plugins are written in Java and they do not contain the source and even the source archives does not contain a full build environment. I think that is quite a hassle and is not user friendly at all. I also do not understand why it was not possible to write a Jelly compiler if performance was an issue.
Java has proven that speed is a relative thing and so I do not see the need for Java plugins. I saw the problems of Java based plugins in the XDoclet project and would loved to see them using a scripting language instead. Now Maven 2 does the reverse with minimal gain but a lot of pain if things do not work as expected and that will happen quite often.

Conclusion

Beside the fact that Maven 2 made it to be released the other concerns are still valid leaving me no other choice than to keep using Maven 1 for now. In my opinion the team failed to meet their own goal of making Maven 2 simpler and easier to use than Maven 1.

Have fun – Andy