Tuesday, February 14, 2006
Maven2 versus The Build Customization
Along with a recent spike in one of the projects I'm working on, i.e. to verify whether we can run a highly distributed system in JBoss Application Server, I also took the opportunity to go and investigate on the applicability of Maven2 as a production build system. Since I'm already quite experienced at working with Maven1 (also known as Ant on Jelly-based steroids), I thought this wouldn't be that much of an issue. But after a while, I found out why they pushed for a new major version number. Besides the absence of good documentation (at JavaPolis I heard they're writing a Maven2 book, which is probably why there isn't much online documentation), this is really a complete make-over of the Maven1 build system. Compared to Maven1 you'll immediately notice that the repository is much better structured. Really new in Maven2 are the explicit build phases. But then again, this is something you already had to introduce in Maven1 projects when you wanted to use the reactor to perform a multi-project build. Another big improvement is the explicit plugin versioning. This is needed to make your builds completely reproducible.
While Maven1 still allows one to do Ant-isch builds, Maven2 completely breaks with this (not taking the ugly duckling maven-antrun-plugin into account). In the beginning you tend to feel that Maven2 really disallows you to do things your way. With Maven1 you just had to create a maven.xml file to start customizing the build of your artifact. To customize a build with Maven2, you're almost forced to create a new Maven plugin, aka MOJO, if not even to define a complete new artifact packaging. But, when you start thinking of it, do you really want to do a custom build?
I think it's OK that it hurts when you're trying to customize your build, simply because you should not be doing so. F*ck the custom builds. In most cases you can get rid of them.
At Sun they spend a lot of time and money defining various J2EE archives to solve all kind of problems. Some with more success than others. So why not simply settle with them and use a build system that is very good at dealing with standard J2EE component formats? It makes your daily life a lot easier (that is, at least the developer part of it, for the other aspects, a good advice, never use standard components). This is especially true whey you're deploying your application on a standard application server like JBoss AS. (As for some of you with who I've got into discussion on this topic, just for the record, MSSQL server is not an application server, thank you.)
One area where I would like to see some improvements is JMX MBean packaging. On JBoss you have a SAR packaging which works just fine, but it's not really a standard J2EE component yet. I don't think Sun's Glassfish will eat it as is. Not only because of the packaging, but also because of the container specific JMX stuff you put inside your MBeans. It would be nice that the most common JMX services, that a J2EE container offers, were somehow standardized. This would make J2EE applications, that need to tweak the container, more container independent. As for the MBean development itself, what is taking the Sun annotation junkies so long to clean up the meta-data API of the MBean? Same remark for the Maven2 plugin API here. XDoclet-alike annotations feel too much like, well, XDoclet. Hopefully we'll see some of the here above mentioned issues getting addressed by JCPs in the near future.
Once you can agree on building only standard J2EE components, I think you gain great benefit from using build systems like Maven2 compared to Ant-based ... systems. Don't listen to the stories of some people telling you that Maven2 still needs some time to mature. That's just script-kiddie nonsense. It had time to mature via Maven1. The only thing that needs to mature is those people's willingness to adopt new ways of building their components according to the (new EJB3) J2EE standards.
While Maven1 still allows one to do Ant-isch builds, Maven2 completely breaks with this (not taking the ugly duckling maven-antrun-plugin into account). In the beginning you tend to feel that Maven2 really disallows you to do things your way. With Maven1 you just had to create a maven.xml file to start customizing the build of your artifact. To customize a build with Maven2, you're almost forced to create a new Maven plugin, aka MOJO, if not even to define a complete new artifact packaging. But, when you start thinking of it, do you really want to do a custom build?
I think it's OK that it hurts when you're trying to customize your build, simply because you should not be doing so. F*ck the custom builds. In most cases you can get rid of them.
At Sun they spend a lot of time and money defining various J2EE archives to solve all kind of problems. Some with more success than others. So why not simply settle with them and use a build system that is very good at dealing with standard J2EE component formats? It makes your daily life a lot easier (that is, at least the developer part of it, for the other aspects, a good advice, never use standard components). This is especially true whey you're deploying your application on a standard application server like JBoss AS. (As for some of you with who I've got into discussion on this topic, just for the record, MSSQL server is not an application server, thank you.)
One area where I would like to see some improvements is JMX MBean packaging. On JBoss you have a SAR packaging which works just fine, but it's not really a standard J2EE component yet. I don't think Sun's Glassfish will eat it as is. Not only because of the packaging, but also because of the container specific JMX stuff you put inside your MBeans. It would be nice that the most common JMX services, that a J2EE container offers, were somehow standardized. This would make J2EE applications, that need to tweak the container, more container independent. As for the MBean development itself, what is taking the Sun annotation junkies so long to clean up the meta-data API of the MBean? Same remark for the Maven2 plugin API here. XDoclet-alike annotations feel too much like, well, XDoclet. Hopefully we'll see some of the here above mentioned issues getting addressed by JCPs in the near future.
Once you can agree on building only standard J2EE components, I think you gain great benefit from using build systems like Maven2 compared to Ant-based ... systems. Don't listen to the stories of some people telling you that Maven2 still needs some time to mature. That's just script-kiddie nonsense. It had time to mature via Maven1. The only thing that needs to mature is those people's willingness to adopt new ways of building their components according to the (new EJB3) J2EE standards.
