Hi Jason, Thanks for the reply. I was following the MNG-1577 debate and agree that this is certainly a step in the right direction. The dependency management solution is suitable for smaller projects with a manageable set of transitive dependencies, although it starts to grow unwieldy with larger projects and begins to resemble M1's flattened list of dependencies.
To give an example of the number of components within our top-level projects: a typical project has 151 dependencies, 89 of which are internal, and the dependency tree goes up to 7 levels deep. We currently have 25 of these projects, each of which are on differing versions of our internal components. It's easy to see that managing a list of 150 dependency versions across 25 different dependency management sections soon becomes a maintenance nightmare. Ultimately we intend to use newest-wins conflict resolution in combination with ranges once MRELEASE-177 is fixed. This should resolve the problem of conflict resolution upgrading transitive dependencies to incompatible versions. Even in the case where ranges are not being used, I find nearest-wins conflict resolution so arbitrary when working on projects with a large dependency tree. We've spent hours digging through dependency trees after encountering runtime linking errors. I do like the notion of applying a chain of transformers to the fully parsed dependency graph, although I assume this would be targeted for 2.1? We've been using 2.0 since the early alphas and are now enjoying a degree of stability, so I'd rather not move to 2.1 until it becomes final. The MNG-612 patch preserves the current nearest-wins conflict resolution, but allows the implementation to be changed for those who require it. I would have thought this would be a good compromise for the 2.0.x branch until 2.1 supersedes it? Cheers, Mark On 25/04/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Not sure if you noticed the MNG-1577 debate, but much of the conflict resolution has been solved by the specification of the versions in depMan ruling out over anything. Now the cases where you are pulling in a transitive dependency that can come from two, or more, distinct subgraphs that you have not defined in your depMan is where some form of conflict resolution might come into play. I think for the most part people would want to be able to see this transitive graph and select the version, until such a time that we can say definitively that the latest version of something is compatible with everything else being used. I think we are quite a ways away from that people would probably end up locking down a version in depMan. But ultimately what is currently there must be replaced by a system that does not alter the graph while the graph is forming. By this I mean the entire graph must be resolved first and any subsequent transformation whether that be scope state changes, version alignment, and repository ordering must be done using standard graph transformation. We simply need a resolution specification and it has to be based on a graph being the fundamental unit of work. There is far too much transformation going on mid stream and it causes problems, and we lose critical information that would make deterministic choices hard if not impossible right now. It will be one of the things I will be bring up at ApacheCon and JavaOne. It is the source of greatest bewilderment to users, especially the behavior prior to MNG-1577. So I would be hesitant to apply any of these changes to trunk. Jason.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
