Friday, January 19, 2007
Maven2 - One year later
About one year ago I switched from Maven1 to Maven2, leaving behind the Ant-isch way of building my software components. Over this year I've started 3 major SOA projects out of which 2 are new products and a few small, i.e. < 20k LOC, projects. Was it worth switching to Maven2? Definitely, though obviously it didn't go as a free lunch. It is very clear that the setup of a software factory using SubVersion, Continuum and a Maven repository is key to manageable software projects. You need to have version control, regression control and release management via a shared software repository. It is reassuring to see that the big players like Sun and JBoss also embrace these principals, and even are/start using Maven2 public repositories to publish the latest releases of their components under development. By sniffing the Sun Maven repository you can even predict releases of their major products like JAX-WS RI.
What Maven2 is still missing is the notion of J2EE dependency contexts. The dependency scoping is not expressive enough in my view. It's very difficult to express, for example, that if dependency X is provided by the EAR, that it should not go into the WAR. And if the container provides X, it should even not go into the EAR at all. Of course some of there rules are very dependent on the class loader behaviour of the container (which is a lot of fun in JBoss AS) wherein you want to deploy your application. Maybe that's why this problem has not yet been tackled to the full extend it should have.
I also get to hear quite often that Maven lacks documentation. This is the general case for most Free Libre Open Source Software (FLOSS) out there, simply because there is no legacy marketing engine behind these projects that forces the developers to produce tons of documentation. "Use the source, Luke." is most of the time the only way to understand how things work. And I for one prefer it that way since it prevents developers from hiding behind bad excuses.
What Maven2 is still missing is the notion of J2EE dependency contexts. The dependency scoping is not expressive enough in my view. It's very difficult to express, for example, that if dependency X is provided by the EAR, that it should not go into the WAR. And if the container provides X, it should even not go into the EAR at all. Of course some of there rules are very dependent on the class loader behaviour of the container (which is a lot of fun in JBoss AS) wherein you want to deploy your application. Maybe that's why this problem has not yet been tackled to the full extend it should have.
I also get to hear quite often that Maven lacks documentation. This is the general case for most Free Libre Open Source Software (FLOSS) out there, simply because there is no legacy marketing engine behind these projects that forces the developers to produce tons of documentation. "Use the source, Luke." is most of the time the only way to understand how things work. And I for one prefer it that way since it prevents developers from hiding behind bad excuses.
