Xavier Hanin wrote:
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
+1
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
mmmmmmmm....
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.
+1
Moreover a lot of iteration can be simplified by introducing some kind
of FilterNode interface and dedicated filters.
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 should also help to introduce a 'Cache' implementation.
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.
np
-- stephane
