Maven is too easy For many reasons, Maven is groovy. It automatically downloads all dependencies for building a Java project, which is a big time saver when you're setting up on a new machine. It imposes a common structure on your project's file system, generates websites, and runs your unit tests. It has fair documentation. Basically, Maven is a useful tool.
But Maven projects can tend toward a chain of stale dependencies. Witness the build script for Jelly circa last week. The Jelly build had 65 dependencies, many of which have never released a 1.0 version. Within Maven, the build appears stable, but this is an illusion. Many of the JAR files listed in that file differ significantly from their HEAD counterparts. And it's the HEAD version that really matters for our ongoing development; the longer an incompatibility goes diagnosed, the more difficult it is to fix.
It's extremely easy to add new depencies in a Maven project, so easy that I think it leads to sloppy dependency management. When the project developer's build tool does not handle downloading dependencies, he is more likely to consider all his options. Should he create a private local copy of the required code, or should he consider if the code is really necessary? Or should he just bite the bullet and add a dependency, which usually involves committing the build changes and publically announcing it?
Maven short-circuits this process by making it possible to easily and unilaterally add dependencies to a project and create a deceptively stable build. (I believe the ease of adding and changing dependencies also makes developers more permissive of large, disorganized libraries.) One could be an active developer and yet be blissfully unaware of the accumulation of dozens of project dependencies. Then you release your project to the world, and the bug reports start rolling in.
Of course, this is not a weakness in Maven, it is a weakness in people. We Java developers aren't used to the power that this particular Maven feature affords, and we abuse it. It allows us in a single commit to make changes that would ordinarily require discussion and approval. That's why I think that tools like Maven make the "commit-then-review" principle insufficient under many circumstances. In Jakarta Commons, I'd like to propose that any changes to a component's external interface (including adding/removing/changing dependencies) should be noted in a separate email from the actual commit. I'm not sure that suggestion will go over well.
It may sound like I'm opposed to using Maven to handle dependencies, but actually I think that it has a lot of potential in conjunction with a continuous integration tool like GUMP. GUMP keeps projects in sync with each other, but it doesn't track the extent to which your dependencies' HEAD versions have diverged from released versions. This is where Maven can help. You can default your Maven-based project development to the most recent released versions. When GUMP notifies you that a dependency's HEAD has diverged, you then know to start tracking it and prepare for the possibility of a point release. Maven could do a better job facilitating this by providing nag messages whenever your project relies upon unreleased or out-of-date libraries.
But it's moot if we abandon all rigor in our dependencies.
12:16:10 PM 
|
