In my search for alternatives for Ant and Maven, Raven crossed my path. Here is a somewhat lenghty comment to Matthieu Riou's blog post Builds And Transitive Dependencies.

Transitive dependencies are an essential requirement dictated by the nature of software development. Each buildsystem which claims to be a real one (including package management), has to support transitive dependencies.

The question is, at what level this support goes and how clever these dependencies are handled. Working with Maven, I can say that dependency handling cannot going worse. Comming from the Linux distribution Gentoo I'm used to a package management system (portage) which is more clever than all tools I've found for the whole Java and scripting language world in terms of (transitive) dependency management.

They support features like slots (different versions of the same package, which can be installed in parallel, without conflict), use-flags (control the features of a package, e.g. if you can depend of two different xml libraries, you can choose which one you prefer), blockers (you can say, what packages (or versions) you don't want to be installed, so the dependency resolver can try to find another version not blocked or another package which provides the same functionality) and some extra concepts like virtuals and providers, the first are meta packages, which handles different packages which e.g. implements the same api (you need only one of them), the later allows you to say that a package is provided, so the dependency resolver will not force an installation.

Another problem with maven was, that dependencies have to be declared on exact version numbers of packages. Why not supporting more than one version, e.g. by providing intervals or using wildcard to match packages by their major version, minor version and patch level version. In Gentoo portage this looks like ">=dev-java/ant-1.6.*" or "<dev-java/ant-1.7". Even the OSGI bundle declaration knows intervals for dependencies in it MANIFEST.MF files.

Don't know exactly, how this is handled in Raven, but I fear that it could become the hundreds buildsystem for Java software, but not the least. Adoption by the community depends among other things on how those dependencies are handled. They have to be handled, but how intelligent and how easy for the package writer, that it the question.

A last thought about repositories (jar, or pom, or gems). Why combining package description and package jars together? There are many jars which cannot be easily copied to a public web address, e.g. because of licensing issues. When tightly coupling of package description (which contain all those dependency declarations) with their jars, such package will never be found on the web. E.g. for maven, you will not find pom's for Sun's Java Activation Framework or Oracle's JDBC driver (There are only conventions in the documentation, how those dependencies should be assigned to groupId and artifactId). When providing a download URL inside the package description together with some check sums, your buildsystem knows how to get them, the repository stays lighter and it is easyier to provide package descriptions for more than one version. It is easier too, to validate if the jar is the original one provider by its creator, or a modified one.

In Gentoo there is the concept of overlays. Overlays are repositories of package descriptions, which can be used to enhance the official package tree, but also to override specific package declaration, if needed. This is an essential feature to be adopted by companies.