Whaoo, very interresting idea there! Here are my tought based on all what has already been said:
About the name and how to place that in the ivy file : Instead of dependencyManagment, what do you think about versionManagment ? And what do you think to replace the conflicts section with this one? Maybe we could also add a <force> sub-tag where we could add some extra-attribute to force. About the inclusion : As Xavier already said, I'm against the idea of inclusion in the repository. But I'm not in the sources. I completely understand the requirement to put in a central place the version constraints for all a project. So I'm +1 for an inclusion mechanism if we find a good one. The problem of such inclusion is that such a file becomes shared by multiple module. It is thus more difficult to get them using some file path, and the module reference seems the good aproach. However, when you want to change a dependency, it is very anoying to have to publish the file first, and then test it. And that's currently a recurent problem when working with multiple modules. Sometimes you would like like your dependency meta-data to be taken from your source workspace, sometimes you want to take them from a repository. I think Maven finds an intermdiary aproach saying it first search in your source workspace to find the module, then it search on your local repository. And about the conflict managment: What will happen when two versionManagment are in conflicts? I'm wondering if the scope of the versionManagment shouldn't be limited to the root module that you are resolving. That would greatly simplify things. Is it too simplist? I'm not sure. But that probably means that the published ivy files should contains some result of the dependncy managment resoluition (which is something that is regularily suggested anyway). -- Gilles Scokart
