A Short Review of Maven 2
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 href="http://weblogs.java.net/blog/schaefa/archive/2004/12/ever_heard_of_a_1.html">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:
- Properties cannot be set outside the POM
- Any dependencies must be provided by repository (local or
remote) and cannot be redirected to a directory within the project.
- For now a project cannot reuse Jelly code from a Maven 1
project and so must convert that code into a Java based plugin.
- 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.
- 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
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
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
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
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
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