Hi All, I've worked on the refactoring of the IvyNode class, I'm not completely satisfied with the refactoring, but I begin to be exhausted by refactorings :-)
Let's say that what I've done is an improvement, but the IvyNode class is still too big and difficult to understand. Anyway, there is a progress (I hope you will see that as a progress :-)), maybe I make further refactorings in this class later when I'll recover from this intensive refactoring experience ;-) So, in a few words, what I've done is split the IvyNode class in several classes. First, I've created a new class, VisitNode, which represents a visit of a node of the dependency graph. Before IvyNode was used to store both data of the node and data relative to the current state of the visit (from which parent do I visit the node, in which root module conf, and so on). Now IvyNode do not store this kind of data any more, it's the responsibility of VisitNode (which stores an instance of the IvyNode visited, and delegates several methods to IvyNode to offer an API quite similar to IvyNode one in 1.4). Besides this split, I've extracted two responsibilities from IvyNode: caller management (who depends on me, now handled by IvyNodeCallers class) and data related to conflict management (now handled by IvyNodeEviction class). IvyNode now delegates to instances of these classes for these features. Ok, I think I'll stop the refactoring for the moment, feel free to give feedback! What I still plan to do soon (next week I think) is to refactor the Ivy API as I've done for deliver (see my mail on refactoring step 3), but I'll wait for feedback for that. - Xavier
