On Wed, 27 Feb 2008 13:25:01 -0500 "Scott Oster" <[EMAIL PROTECTED]> wrote:
> Point taken on the desire to not use the work around; I was just > suggesting it as an, albeit suboptimal, way to work with the support > that is there today. > > On your second point about writing a tool to automatically specify the > versions, I'm not sure I really see the point of using a system like > Ivy if you want to "hard specify" every single version of all your > dependencies. First of all, I can use all of ivy's power to create that versions file. A task that is really hard to do manually. The dependency resolution is just moved from each ant invocation to a specific "integrate a new dependency" step. Also I can have a central repository to share the work and there is meta-data attached to the modules, which I would lose if I just copy libraries in a local lib/ directory. > If you don't do "all" of them, you are left with the > same potential need for automatic conflict resolution, as some new > version of a module may introduce a new conflict, which you don't > have a hard specified rule. I would never do automatic conflict resolution. A conflict has to lead to a build error, in which case I would resolve the conflict manually. I can do this with the conflicts/manager section, but, as posted in another mail, I would like to have support for multi-module projects. > Therefore, I think what is needed is the ability to provide Ivy with > mediation/arbitration rules which are consulted at the time when > decisions are being made on which versions to use for transitive > dependencies. Currently Ivy supports plugging in logic to the > decision only when there is a conflict; what is missing is just a way > to plug in logic when there aren't conflicts. I think a new section > in the Ivy file which contains the current "conflicts" section, and a > new "versioncontraints" section would suffice. Fair enough. whatever best fits the ivy philosophy. > I agree with other > posts "dependencyManagement" is a poor and confusing name for such a > section, but don't really have many better suggestions, but feel the > name should be derived from the fact that it's a place to provide > rules to the engine when processing transitive dependencies. A > "manager" syntax similar to "conflicts" would probably suffice. You > could then implement your own versioncontraints manager to read a > "versions file" if you liked; others could simply hard-code the > versions they want for specific transitive dependencies. > > Scott >
signature.asc
Description: PGP signature
