On 1/30/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
+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).
I agree that reading the Ivy class is not too difficult, but it's a
lot of reading :-) More than 3000 lines for a single class, it's just
too much. For IvyNode the problem is different, not only the class is
long, but the problem it solves is complex, and the class is very
badly documented. So I agree a good amount of work must be done on
this class.
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.
I think it really depends on what you do. IvyNode is an internal
class, and you don't have to care about it unless you wan't to
improve/fix the resolve process, which is not so frequently the case.
On the other hand, as soon as you want to use Ivy as an API, you need
to use the Ivy class itself. That's why I think refactoring the Ivy
class is very important too.
- Xavier
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
