By the way, has any further work been done on this issue?
Lately, I've been working with Maven multimodules with parent poms and I'm starting to think it provides some useful features which currently can't be easily replicated with Ivy.
First of all, let's suppose we have a multimodule Ivy project, each submodule having its own ivy.xml. One example of such a multimodule is a project consisting of an ear, wars, ejbs and jars. The submodules have common dependencies, for instance a jar project depends on dom4j.jar to compile and the ear project depends on dom4j.jar to include it inside. In this case, both the jar project and the ear project clearly have a dependency on dom4j.jar:
<dependency name="dom4j" org="apache" conf="compile" rev="1.4.1"/>
<dependency name="dom4j" org="apache" conf="runtime" rev="1.4.1"/>
For instance, the revision of dom4j is included in several places and when you need to change the revision, you need to change it in many places.
In Maven, you can define the revisions in parent pom's dependencyManagement block in this manner (note that this isn't Maven's syntax, I'm just trying to explain the idea):
<dependency name="dom4j" org="apache" rev="1.4.1"/>
After this the subproject can use dependencies like this, omitting the rev:
<parent name="myparent" rev="1.0"/>
<dependency name="dom4j" org="apache" conf="compile"/>
If you want to change the version of dom4j, you just change the version in the parent pom.
Another thing that the parent pom provides is that if it finds the right revision in some path ("../pom.xml" by default), it will use that instead of the published on in repository. This is really useful when developing in IDEs or otherwise, because it's often too slow, cumbersome or even impossible to go.
1. publish parent ivy
2. resolve submodules
That's just my experience. I've used a submodule which defines some common dependencies in an ivy.xml but I don't find it as useful as the parent project of Maven. Thoughts?
Oh, and third opinion about including the parent vs. resolving it from a repository: If you just include it, the submodule cannot be reliably rebuit again as a single entity. For instance, if you checkout just the submodule with a some tag or certain branch, you don't really know which revision, if any, is in "../ivy.xml" or "../parent/ivy.xml". I don't think is issue is necessarily about whether the published metadata is merged or not, it's more about how the parent ivy is found while doing a resolve.
In Maven, if the parent pom on the directory has a revision "1.10-SNAPSHOT" and the child refers to parent "1.10-SNAPSHOT", then Maven uses the file on the directory, otherwise it searches the repository. I'm not sure how exactly it should work with Ivy's static and latest.* revisions, but in my opinion, while developing on a local workstation, you often want it to be included, but when building official builds on a CI server or doing release builds, you want it to use the published version from repository.
Going on this issue even further, well, even in Maven it's really hard to publish the parent pom alone or to publish only a subgroup of the projects. For instance, since the parent pom resides in the root directory, if you tag it, the SCM system usually tags all the submodules in the directory tree as well, etc. With the current build tools, it seems it's very hard to make a build system which supports large multimodule projects where you sometimes want to handle the multiproject as a whole and sometimes publish only parts of it.