I like this whole discussion with the ability to more closely specify transitive dependencies. However, I would add one more requirement. I think this control should also be allowed to be specified in the <modules> section of the settings file. This is very important when you are in charge of an entire company's modules each with their own release schedules and combination of modules and branches. I could spend my time writing settings files for each product release with complete control over what branch of what modules and even what explicit revisions should be used. Then a given developer working on a given product release would simply set an environment variable or something to control which settings file to use. Then he automatically gets the blessed configuration for that product release. I don't want to have to go to each ivy file and make changes all over the place which could easily result in branching each module's source code just to get a new ivy.xml file.
This concept is very similar to Clearcase's config spec idea, except I call it an Ivy Release Spec. --- Shawn Castrianni -----Original Message----- From: Harald Braumann [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 27, 2008 12:50 PM To: [email protected] Subject: Re: specify versions separate from dependencies On Wed, 27 Feb 2008 19:02:57 +0100 "Xavier Hanin" <[EMAIL PROTECTED]> wrote: > On Wed, Feb 27, 2008 at 6:35 PM, Harald Braumann <[EMAIL PROTECTED]> > wrote: > > > From the many, many hours of experience I have in fixing dependency > > problems, I can tell you that for any reasonable complex project, > > automatic conflict resolution does not work and leads to a lot of > > problems and headache. Thus I want to be in control of the versions. > > Once this is supported by ivy, my plan is to create a tool that > > creates the versions file for you. It would resolve all the > > dependencies recursively and write the versions file. It would also > > tell you all conflict, which you have to resolve by hand (IMHO the > > only sensible thing to do). If you change any dependency, you re-run > > the tool and it tells you all the new conflicts (by comparing with > > the old version of the versions file). > > Interesting idea. Note that if you need overriding only when you have > conflicts, the conflicts/manager elements in Ivy files can already fit > your needs AFAIU: you run a resolve with a conflict manager which only > collects conflicts from your tool, then ask the user to select > versions, and create the conflict management section to include in > your main ivy file. Since inclusion is not (yet?) supported, you still > need to do some kind of automatic merging before giving this to Ivy, > but this is not the hardest part. The end result would be really close > to what you would have with a dependency override mechanism, except > that conflicts would still appear as conflicts in dependency reports. > WDYT? That would solve the problem of overriding conflicts. But in addition I would like to be able to specify versions to use for multiple modules in a single place. Modularising a project has a couple of advantages. But it also adds complexity, which makes modularisation kind of a PITA. Our project, and also some open source projects I follow, which went the stony path of modularisation (see e.g. X.org) put a lot of effort into custom tools just to make the building and installation somehow manageable. And still they have problems constantly. Now I think that it doesn't have to be like this. The pain could be alleviated by proper tool support and a dependency management system seems to be the perfect match. harry ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
