Maven 2 Reliability

Meant as a reply to a rather old blog post of Charles Miller about why the Maven 2 concept is broken by design.

Reliability

Consider two pieces of software. One uses maven (and 1–n artifact repositories) to manage its dependencies, the other keeps all its dependencies in source-control. How many potential points of failure are involved in checking out and building each product?

Touché. A project which has all its dependencies stored locally (e.g. in version control) is of course more reliable in regard to the build. However, imagine your project has a "foobar.jar" in the lib/ folder and you have no idea which version that is and whether it's an official version or not. No way to find out. Maven helps here, as it guides people to use official versions or at least do a proper release of a patched library. That's documentation and a good thing.

Repeatability

Maven seems to try as hard as it can to prevent this. Files go missing from public Maven repositories and suddenly a whole swathe of historical versions of open source projects can't be built without hacking. ibiblio reorganises its directory layout and chaos ensues. Imagine what happens in ten years time when maven has been superceded by some new tool, public maven repository maintenance is an afterthought, and you desperately need to patch some legacy Java app?

If we go a few years into the future, this might become a problem though, and I can see that coming. Maven repositories vanishing or being cleaned up, domains out of order, URLs broken etc. I think that, as long as a project is active, this is not a concern. For enterprise projects, this disadvantage can be seen as an advantage though. We're using our own enterprise Maven repository internally. Everything, including external artifacts, is stored there. Building in offline-mode is necessary for repeated builds even after years. So, you're forced to keep all what you need locally, but you can still benefit from the Maven features like dependency management and release process. Certainly there will be efforts to make Maven more .. "aware" of such environments - like storing Maven plugins locally, too, and becoming more stable in regard to release of new Maven plugins (i've seen so many "1.0-ALPHA3" releases of maven artefacts and plugins - that should not happen at all). Eat your own dog food, Maven guys! Make proper releases.

Responsiveness

Tracking down dependencies and sorting out their transitive relationships is a tricky task, but it's a tricky task you only ever have to do when you modify your dependencies. Maven, on the other hand, wants to do this job every time you build, which adds a huge responsiveness overhead, as the "pom" definition files of each dependency must be retrieved and analysed alongside their jars.

I can see the point here. It's just an implementational bug in my eyes. Maven could indeed store the calculated dependencies, e.g. in a separate dependencies.xml. However, I see Maven as it is - a build system. Not a realtime-compile-package-deploy-tool. Building a project should be done solely in the IDE while in development. There should not be any need for tools like m2eclipse in a project anyway. At least, not integrated into the normal "compile my classes" process. Maven is a build system and should be seen as this. Run Maven on your CI server and once in a while (daily) on your developers machine. But don't run it every 5 minutes. If you do, your development environment setup is ill-designed.


There are a lot of repositories out there, and Maven is only one of it and it does the job. Not a perfect one, but sufficiently. All those repositories suffer from the same problems: dependencies, versioning hell, missing tool-support, no plans for the future (after-life) etc.

Take Gentoo for example - they're relying on their package repository and all their clients do so. They don't seem to care about stuff like "Omg, when the Gentoo repository won't be there any more in 5 years, i won't be able to update my production Gentoo Server with all that critical business applications running on it.". They rely on the fact that it will manage itself somehow. If the repository goes out of order, there will be something new and hopefully better so I can still update my machines. Same thing with Maven-based Java Projects or IDE Plugins (Eclipse Plugin HellTM) and any other software system which makes heavy use of the Always-Online-itis.

We should stop using/relying on the internet for software development.

• Comments (0)
• Trackbacks (0)