Hi, In my company we are investigating how to use conflict managers and eviction strategies in a large enterprise - and by large I mean hundreds of modules and independent development teams.
The main problem we are facing is how to deal with multiple versions for the same artifact selected over different paths in the dependency graph. It seems that the maintenance problem could quickly scale out of control. Imagine the following graph: A->B A->C B->D C->D B and C can evolve their dependencies on D independently; but A has the problem of choosing the versions of B and C, taking into consideration a possible conflict when selecting version D. Let's say that in the repository, we have the following configurations: B v1.2 -> D v1.2 B v1.1 -> D v1.1 C v1.1 -> D v1.1 C v1.0 -> D v1.0 A can use static versions fo B and C. But as the size of the dependency graph becomes larger, this becomes more and more of a problem as you have to choose dependency versions based not only on its own merits, but also on how compatible their entire dependency subgraph is with your other dependencies. Imagine that instead of two you have ten dependencies, each one with ten or so dependencies, and that the version conflict is five levels removed from your level. If A uses "latest" for his dependencies, we can either end up with untested configurations (if we use the latest-revision strategy) or build failures (if we use strict, which assumes that Ivy-474 is fixed). None of those two approaches is desirable; untested configurations (in our example, C v1.1 using D v1.2) could lead to hard-to-debug errors at runtime, even more so as the graph grows. Build failures are better - fail early always is - but that moves us back to the original scenario where A has the burden of experimenting with dependency versions until it can find one that won't break. One possible solution would be a conflict manager that automate the manual process of finding the latest configuration that won't have version conflicts. It could work by implementing a depth-first analysis with backtrack capabilities (Prolog, anyone?) where the latest version of a dependency would be selected by default, but if later a conflict was detected with one of the dependencies it introduced, the conflict manager would undo that selectio, pick the next one, and try again. Or perhaps it could be solved with a breadth-search strategy, which would probably be able to detect collisions earlier. But it would have to hold a lot of state in memory (all the versions of all the modes) which could become quite expensive. Anyway, my questions are: * Has anybody looked into this solution, or has a better idea of how to deal with the problem I described? * If I was to implement this conflict manager, could it be done based on one of the two basic conflict managers (latest-cm and regexp-cm) or would I have to create one from scratch? My guess is the second option, but perhaps they can be tweaked to hold enough information to make the decisions I described. Thanks, Nascif
