Introduction
I started using m2 extensively in the past 3 months in various projects. During that time, the m2 core came to be released, then the plugins. In the course of this experimentation/work I encountered various successes and failures. On a particular project with a client (migration of a 150000 lines of code project built from maven/ant to maven2) we had a particular hard time.
First m2 was missing some features for our build, in particular to build webstart applications. The functionality to do that (sign the jars, package the JNLP application, …) was missing in m2, and m2/ant integration wasn’t an option. So I’ve had to implement it. Then I’ve had to slightly tweak my maven build, which was relying too much on various local tweaks in maven.xml files. Finally I’ve had to change somehow the way we produce our final artifact for the various customers. Customization now happens at a different phase of the overall building process, which matches better our work model. m2 profiles were used to make this work.
Doing the migration I lost many hours due to various m2 issues. All in all I think I encountered around 15 issues that directly affected my productivity. I’ve fixed many of those, some are still unpatched and working with m2 today still requires to build my own patched version of m2, and upgrade a couple of times per week. In terms of time, my estimate of the time it would take to write the Webstart plugin was roughtly correct, but I spent much more time trying to work-around m2 bugs and/or fixing it.
Potential Improvements
I know that some people are going to not be particularly happy by this section. But someone has to say it 
Here follows a list of issues and potential recommendations:
- bugs, regressions and maturity. Today that’s the main issue to me. As soon as you start using maven/pluggins in ways people haven’t used them, you walk on eggs. In particular, I’ve had many plugins fail when used within the reactor. To prevent these issues, a developer methodology to test plugins should probably be defined to help plugin writers avoid common mistakes.
- debugging the core can be a daunting task. Writing unit tests for it is even harder. Even Jason says it.
- in case of a failure, m2 tells you to rerun the build with the -e option to get a stack trace. That’s completely counter productive. Do not ask me to rerun my full build with -e enabled. Just keep track of the failure somehow, and display it for me.
- XML verbosity. I am sort of tired to write very verbose XML files. First spring now maven2. Yack. Example: try to manually change the version of your multi-project. If you don’t use the maven release plugin (which is known to have some issues), you will have to change all your poms. Why can’t this be in one place? This is linked to the maven way of defining poms, but you wonder if KISS just went away. I don’t have a better solution to propose for the general XML verbosity issue though, apart from designing very carefully the maven’s core. Maybe that will be partially addressed in 2.1.
- better installation. When you rebuild and reinstall some of the core m2 modules, you will sometimes need to copy them into your M2_HOME/lib directory. That was maybe fixed since 2.0?
- documentation. Although very good, some cases are not covered enough. In particular, the model document is sometimes not easy to browse. I wish it was formatted like the CruiseControl config file was. The documentation (guides) is also perhaps not well structured to my taste, and lacking in some areas, probably because it is automatically generated.
- similarly m2 introduces many new terms & concepts. A m2 dictionnary would help (note: the m2 book is on its way, so that may come in the form of its index)
- plugins style consistency: m2 developers should perhaps setup a structure to review initial design proposals for externaly hosted plugins to make sure they are developed to fit correctly within the m2 model and philosophy.
- for plugin developers, I spent quite some time trying to find out which dependencies I needed to add in my pom, and which version. When I didn’t have my IDE opened on the maven project itself, I spent most of my time doing
locate ClassName to find out the module the class was pertaining to then check in the logs whether the required pom was there or whether it had the right version. That worked because I had the whole m2 source on my machine, as well as plexus source, doxia source… We maybe need a sort of versioned jarhoo for maven 2 related projects?
- I think that it’s very easy to not find out about particular maven issues if you have a locally deployed dependency and a broken maven that incorrectly searches for the dependency. For similar reasons, I wonder if m2 developers tend to have an environment that doesn’t let them find out the issues user face (in particular dependencies issues). I may be wrong there, so I won’t extrapolate too much. Now I wonder how this issues will affect Continuous Integration setups. For the moment I recommend using a different repository for each independent project your are using. You should try to avoid any side effect your local repository may introduce.
- upgrading m2 without cleaning your repository can let you in a dependency mess (in particular if you had a snapshot version installed). Cleaning your full repository forces you to manually reinstall all some artifacts (jdbc, jta, …). Be use to set up a corporate repository soon enough.
- slow slow slow ibiblio. Anyway, you shouldn’t completely depend on the Internet. Use a mirror and even better maven proxy.
- maven now has many plugins which are small projects themselves. These projects have their own release cycle. That’s a big departure from the way traditional open source frameworks have been released (ant, cruisecontrol, etc…). There are obvisouly benefits (easy to push a fix to the users) but that creates other issues. You may introduce breakage if your poms haven’t been correctly specified and a regression is introduced. Similarly it’s up to the bug reporters to make sure their issues are taken into account. Sometimes one will have to poll the developer list and notify the developers that a particular issue is to be included in the release. That will go hopefully away when the code will mature. Still one can see the typical dependency issues that have plagued Linux distributions for years.
Good parts of m2
Not all is that bad!
- the m2 developpers have been very quick at empowering me. They gave me committing access to the mojo-sandbox where I’ve been able to upload various plugins required for me to work that could be useful to the community. I believe this to be a very good move from the official developers of the m2 related toolset. The m2 community is indeed very active, and allowing people to be gradually involved in the project can only benefit them. I am also pretty satisfied with mojo community. I’ve received a lot of enhancements in the form of patches and ideas that now will soon make some of the plugins really production ready
- I find the standard lifecycle and directory layout a breeze
- mailing list/IRC support: mostly good, even if it tends to be less efficient when a people are busy (preparing a release, writing a book…)
- the quality of the project (and documentation) is increasing. The trunk seems to be broken less than before, and the developers are willing to make maven 2 a better product.
Conclusion
m2 shows great promises. Its current state is not completely ready for production (at least not for all kinds of projects), altought it is getting closer and closer. Depending on how you will use m2, you may encounter many many small irritating bits, or slightly broken features there and there. When trying to migrate a small and relatively heterogeneous project, you might spend too many resources fixing internal issues or adding missing functionality through plugins. On the other side, the bigger your project, the more homogeneous it might be. The economy of scale will reduce these migration costs. With regard to starting a new project today, I definitively advice you to consider using m2, especially if you don’t need fancy features. E.g. if your project is a back-end sort of things, like combining layers of jars together into a single project that do not require many customizations, m2 is definitively a tool to look at for your infrastructure. As with other types of projects, in particular big J2EE projects, work is being done to produce sets of guidelines that should make your life easier.
The plugins I looked at were of differing quality but most were good. For developers, if you want to develop a plugin, be sure to spend time understanding the concept of life cycle. I definitively lost some time here jumping too early into the code (for my defense, the documentation was shallower when I started). Spend also time understanding the way dependencies and release mecanism work.
Many people are coming to maven because of dependency management. If you just need dependency management, maybe you can get away by using the maven2 ant tasks. Even with those, dependencies issues are problems that Linux distributions have had since their inception and that won’t disappear tomorrow. If you choose to use transitive dependencies, you just trade one problem for another one, hopefully smaller. But remember, dependency management is only as good as your poms and release process can be!
All in all, I believe m2 is going to rock, but it will take some time, because it changes the way we do things. M2 brings in a long awaited set of features really useful for managing big projects. Its philosophy can sometimes feel to be in your way to gets things done when a particular feature is missing or an issue affects your setup, but I think it pays a lot on the long run to follow these somewhat enforced guidelines. And if you use maven/m2 just remember one thing: don’t try to fight it.
I will give it a 3.5 stars out of 5, but I believe it will be worth 4 or 4.5 within the year.