Andreas Schaefer's Blog

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 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

Comments

• I currently use Maven 1 and have been looking at moving to Maven 2, but you have made some interesting points.

  
  I'm very disappointed that Jelly is not supported. It might not be the best scripting language in the world, but for calling ant tasks combined with a bit of logic it's pretty good. It's certainly a lot better than trying to write the same thing in pure Java code.
  

  Posted by: prunge on December 07, 2005 at 06:44 PM

• The statements that jars on which the project is depended must in a repository (at least the local one) is not true. Take a a look at Introduction to the Dependency Mechanism and search for System Dependencies. The following is an example that I used in a project where the javamail API are stored in the lib directory of the Maven2 project:

  
  
  javax.mail
  mail
  1.3.3_01
  system
  ${basedir}/lib/mail.jar
  
  ....

  
  Or am I missing the point of your comment?

  Posted by: gerovermaas on December 08, 2005 at 04:06 AM

• The example got mixed up my previous post... this one should be better

  <dependencies>
  <dependency>
  <groupId>javax.mail</groupId>
  <artifactId>mail</artifactId>
  <version>1.3.3_01</version>
  <scope>system</scope>
  <systemPath>${basedir}/lib/mail.jar</systemPath>
  </dependency>
  ....

  Posted by: gerovermaas on December 08, 2005 at 04:07 AM

• Hi,
  we are currently migrating from maven 1 to maven 2. I might have a few hint that can help to solve some of your problems.
  1. Properties cannot be set outside the POM
  The properties section of the setting.xml (or profile.xml) can add arbitrary key/value pairs available in your pom. I found some help here: http://maven.apache.org/guides/introduction/introduction-to-profiles.html

  2. Dependencies must be in the Repository
  We setup our internal repository and I might say, it is a very straight forward process. If your concern is about where to host (and publish) your opensource repository, I can't help as we are using maven in our company and haven't hosting concerns. A other option could be to improve the maven repository itself. See the procedure here: http://maven.apache.org/guides/mini/guide-maven-evangelism.html
  3. No Jelly in Maven 2
  That was new to me (I thought Maramalade was available the make the bridge). What about Beanshell ? Anyway, in my opinion and experience, xml scripting get quickly unmainaiable to non-author of the script. For me, java would me more natural but I haven't experimented now.
  4. Build Hierarchy
  I do not have such requirement my self, but as far as I know, you can hook the build process, but I don't know if it could solve your ordrer concern.
  5 Source of a plugin
  I agree with you, it helps in the learning process. I'm going to develop some plugin myself next week, so I'll see how hard it is to make it work.
  Conlcusion
  I like also a recommandation of Vincent Massol, who recommmand to run maven 2 in parallèle of maven 1, and wait until it's mature enhough to handle the problem you have. (more info here)

  Posted by: yann_andenmatten on December 08, 2005 at 04:08 AM

• I think some of your points are valid - especially obtaining source code of plugins, and the ability to hook into the build process. However, saying that the lack of these two features is "throwing the baby with the water" is..well...a little over the top, no?

  Maven 2 brings many other improvements that - provided we give it time to mature - will prove well worth the while and hassle. For instance, the notion that I can run mvn install or mvn deploy regardless of whether I'm working on a webapp, ejb project, java app or any other kind of application brings tremendous power. It can't get any easier than that to build a project you don't know.

  More than that, the switch to java-based plugins is well justified - have you ever tried to maintain (long-term-wise) any Jelly code? If you have, I'm sure you'd agree that it's a pain in the wrong place. Java-based plugins have disadvantages as well - source-code (or lack-of) being one of them. But that's being solved.

  So, in short: while in the short-term I do agree that Maven 2 needs to mature a bit (if only because its plug-in-set is not yet fully ready and provides the entire M1 feature set), in the long term - Maven 2 brings fresh and sweet promise to become the best build tool around.

  And if not - well, there's always Ant, no? ;-)

  Posted by: arikk on December 10, 2005 at 06:47 AM

• Started an in-depth look at Maven 2 today. Came across multiple problems when generating reports.

  
  The CheckStyle plugin does not allow custom rules to be used (although the latest version that isn't in the repository yet says this has been fixed). Unfortunately the latest version in the repository causes an exception every time it is run so I had to revert to the alpha version which at least does something.

  
  The Javadoc plugin when generating a report gives back a blank page with no links, even though the rest of the pages are generated successfully. Maybe there is a property to fix this somewhere?

  
  No Source XRef or Test XRef generating plugins as far as I can see.

  
  A lot of the plugins are still in alpha or beta and have poor documentation compared to the Maven 1 versions.

  
  There are a lot of really cool features in Maven 2. Automatic downloading of the latest versions of plugins is great. The Maven 2 plugins need some work before we can start using it seriously. But Maven 2 has a lot of potential.

  Posted by: prunge on December 13, 2005 at 05:46 PM

This work is licensed under a Creative Commons License.