On Thu, Feb 28, 2008 at 9:52 AM, 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 ? Sounds much better. But does this still make sense if we allow to override arbitrary extra attributes, and branch? > And what do you think to replace the conflicts section with this one? I'm really in favor of merging the two, they are very related. But we still have to find a good syntax. > > Maybe we could also add a <force> sub-tag where we could add some > extra-attribute to force. Why not, but in this case I would keep it consistent, and put revision forcing here too. Maybe an example of the syntax you envision would be more explicit? > > > > About the inclusion : > As Xavier already said, I'm against the idea of inclusion in the > repository. But I'm not in the sources. So I think we share the same opinion. Great! > 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, This is not much different from the settings file loading. We provide file based or url based loading, and until now people find their way with that. Maybe we could stick with that to start, and then review the loading mechanism. If we find a good loading mechanism, I think we should apply it to both inclusion and settings. 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. Agreed. > > And that's currently a recurent problem when working with multiple > modules. Agreed too. > > 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. Exactly. And this is not only true for module metadata, but also for artifacts. To go even further, in multi module development, it would be even better to be able to "understand" exploded artifacts (being able to use a "classes" directory as an equivalent of a jar). But I think we can keep these subjects separated, and address one thing at a time. > > 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. But you need conventions in your workspace layout to do so, and we haven't in Ivy. IMHO this could be adressed by a kind of publish which just tells Ivy where the sources for the module and its (possibly exploded) artifacts are. Then Ivy would be use this source location as a kind of local repository for one module only. But once again I think we can split the requirements and ideas, and focus on one thing at a time. > And about the conflict managment: > What will happen when two versionManagment are in conflicts? I think we should use the conflict manager in this case. I don't it's simple, but I think it makes sense. > 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). Indeed, storing the dependency closure in the published Ivy file would simplify the dependency resolution process, and it would greatly improve performance too. So I'm in favor of this improvement too. That being said, I'm wondering if we could make this mandatory in the case of usage of versionManagement section. This would mean that we wouldn't support version overriding in ivy files in repository, only dependency closure. But I don't know which way we should go... Indeed I think we have to support version overriding in repository files to be compatible with maven2 (still have to test to see how conflicts are handled in this case). So I'd rather go with supporting version overriding in repository files, and consider the publishing and usage of dependency closure a separate feature. Xavier > > > > -- > Gilles Scokart > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
