My personal tipping point for Maven
I have always resisted using anything other than ANT to build my Java projects. I mean, if ANT can do the job and everyone else already has it, why do I need to learn anything else, right? However, Maven2 has finally reached the tipping point for me last week.
First, the Seam team has officially made Seam builds with all its dependencies available from a Maven repository. Seam has been using Maven to manage its own builds for quite sometime now. But the new Maven support makes it easy for developers to set up Seam application projects in Maven — it is now quite easy to make sure that all 3rd party JARs you use in your application are the ones tested by the Seam team.
Second, Netbeans 6.0 released a beta, which boasts Maven project support. You can now open Maven project directories directly in Netbeans, and have all the source/resources/test packages listed in the project browser with all the correct classpaths. Okay, you still need to install the Mavenide plugin. As a long time Netbeans user, I found it reassuring to see that the Netbeans team is committed to bring first class Maven support to the IDE.
Last and most important, the R&D team at eZee has decided to use Maven to manage our internal projects. The rationale is that since we are starting brand new projects, we are not chained to legacy ANT scripts. We have an opportunity to start fresh from Maven. Why not try it? Even if Maven does not work out, we still have an opportunity to convert the projects to ANT — but we will all learn a lot of the exercise.
So, how do I like Maven after a week of using it in real life? I have to say that I really liked it. Maven takes a very structured approach to build management. It is not as flexible as ANT. For most “standard” project types, Maven just supports them out of the box — there is no build script to write — just put your code and configuration files in the right default directories and you are ready to go. Speaking of “configuration by convention!” However, if you want to do anything not supported by default, you have to write code to plug into pre-defined integration points in Maven.
Maven really reminds me a lot about JSF — it does not allow you to do random scriptlets like JSP, but it provides integration points where you can heavily customize the behavior of the system. Sure, it is more work to create code that conforms to the “framework”. But you also get more stability and maintainability out of it. I am hoping that Maven can allow me to achieve the same!
October 1st, 2007 at 2:44 pm
Glad that you are enjoying Maven 2. While the quirks are well documented, I am hoping that like with all projects, they are just rough spots that need to be smoothed out.
Two comments on your posting. First, Mevenide has been available in NetBeans for a while. I believe it supports NetBeans 5.5 as well as the upcoming NetBeans 6.0. IntelliJ IDEA also supports Maven 2 projects directly. The jury is still out on the quality of the Eclipse support.
Second, a lot of people think that Maven 2 is not as flexible because it doesn’t have random scripting support within the project file. If you are a big Ant user, you can always just use the Ant goal to establish an inline Ant target that will be attached to one of the life cycle phases.
However, the main reason that Maven 2 does not support general scripting in the project file is because the whole idea is that if you need to script something, you should create a plugin to do it. Then, your build remains declarative, but your plugin can fly to the moon and back if it wants.
I think people have gotten so used to “programming in XML” that they are afraid to write a little Java. I encourage you to give it a try if you get stuck at the limits of Maven.
October 1st, 2007 at 5:51 pm
Thanks Dan.
Yes, I agree that the declarative (or “inflexible”) nature of Maven XML files is a strength rather than a short coming. That is why I invoked the JSF reference in my post.
cheers
Michael
October 2nd, 2007 at 3:41 pm
Yep, I thought that was an excellent correlation.
What’s funny is that JSF had (has?) early issues as well. Life cycles are not easy to get right the first time. They are like processes in that way. You are imposing a restriction to get better productivity, but sometimes you cut out or miss some important needs. That doesn’t mean you have the scrap the life cycle, but rather figure out how to weave in (pun intended) the missing coverage.
October 4th, 2007 at 12:10 pm
Yes, the quality of Eclipse support is somewhat questionable. The m2eclipse plugin helps, but make sure you manually install the latest stable build (the Eclipse update is quite out of date the last time I used it) or you will lose support for cross-project dependencies.
The most pressing issue to resolve within Eclipse is the Maven hierarchical project structure. The hierarchical structure is an excellent project organization technique, but is not directly supported by Eclipse. If you use a flat structure, you can organize your modules as projects into Working Sets, but it is certainly a work-around. Hopefully as Maven continues to gain popularity Eclipse will add support features.
October 5th, 2007 at 8:36 am
Dan, you can add ant script directly to pom in maven via ant-run plugin which allows you to plug ant scripting to any phase and you can do almost anything you want, it’s just that the build lifecycle of maven should be respected. That way I built in deployment to websphere via maven (which is only possible by ant scripts provided by IBM).