+1 , +1, +1... :-) Personally, I think the most important part is the refactoring of the IvyNode data structure. For me, this part is the most difficult to understand (when you don't understand what is in a field, you have to search for the setters, and understand the callers on multiple level ...). The flow in ivy class itself is much more easier to understand (a top-down reading is easier than a bottom-up).
Moreover, when you start to code something in ivy, you most probably start by writing or extending a task, which will in most case have to handle the IvyNode. When you start, you care more about the IvyNode than about what is behind the Ivy class. But of curse, clarifying both the Ivy and the IvyNode is better. Gilles > -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Monday, January 29, 2007 7:24 PM > To: [email protected] > Subject: Ivy refactoring > > Hi All, > > As discussed several weeks ago, I think that Ivy needs some > refactoring to ease the understanding of its code base for > new developers. > > I plan to start this refactoring tomorrow, it will introduce > many changes to try to get things cleaner and easier to understand. > > My first focus will be: > + split the Ivy class by features in: > ++ IvySettings, which will be the result of the configure step (I do > not use configuration to avoid confusion with module configurations) > ++ ResolveEngine, which will be responsible for dependency resolution > ++ RetrieveEngine, responsible for the retrieve step and so > on for each > ++ features/tasks > The Ivy class will preserve an API similar to the existing > one, but will only be a Facade to other classes. Moreover, > methods taking too many parameters (like resolve) will be > refactored to take a fewer number of parameters, using a > class (like ResolveOptions for instance) to group those which > are not first class parameters > > I will also work on the dependency resolution algorithm, and > especially on IvyNode. I will split it into at least two > classes, one representing the node in the dependency graph, > and one with data related to the traversal of this graph > during the resolution process. > > Another thing I'd like to address is to reduce the number of > classes in the same package, and the number of packages of > the same level (namely org.apache.ivy.* packages), to move to > something more structured and hopefully less confusing. > > This refactoring will introduce many API incompatibilities, > but it should hopefully help people to understand the code. > > This is only the big picture, I'll keep you informed of my > progress, and try to process by steps to allow frequent > feedback and discussions. > > - Xavier
