On Thu, 28 Feb 2008 09:52:40 +0100 "Gilles Scokart" <[EMAIL PROTECTED]> wrote:
> 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. Ah, the problem of binary vs. source dependencies. So I'm not alone with my problems, after all. So far I haven't found a good solution for this (not even theoretically). > 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. I don't know, what you're referring to, here. Maven only uses installed/deployed artifacts. The eclipse plugin, however, which creates .project and .classpath files for eclipse from pom files, can create source references. But this only works, if the pom file in the dependee's source directory has the same version as is specified in the dependency of the depender. So whenever you change the version of one artifact, you have to change dependencies in all depending artifact. I've hacked the eclipse plugin to ignore the version, but this leads to inconsistencies, as it now depends on where you build: from eclipse or from command line. > 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). If the version overrides are resolved transitively, then I think the only sensible thing to do in this case is to use nearest. If some kind of parent mechanism is used, there can only be one parent, so there won't be any conflicts with nearest. If you can specify overrides in multiple places, like in the ivy file as well as in the settings file, as was suggested by Shawn, then a strict precedence has to be defined (settings file overrides ivy file). harry
signature.asc
Description: PGP signature
