[jira] Resolved: (IVY-434) refactor Ivy source code to improve readibility

["Xavier Hanin (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IVY-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xavier Hanin resolved IVY-434.
------------------------------

    Resolution: Fixed
      Assignee: Xavier Hanin

A large amount of work has been done in this area, I think Ivy source code is now much more readable and maintanable. Hence I mark this as resolved for 2.0.

> refactor Ivy source code to improve readibility
> -----------------------------------------------
>
>                 Key: IVY-434
>                 URL: https://issues.apache.org/jira/browse/IVY-434
>             Project: Ivy
>          Issue Type: Task
>    Affects Versions: 1.4.1
>            Reporter: Xavier Hanin
>            Assignee: Xavier Hanin
>             Fix For: 2.0
>
>
> Ivy needs some refactoring to ease the understanding of its code base for new developers. The migration to ASF is good moment to make this refactoring.
> Note that I open this issue really too late because most of the work is already done, but I want to keep track of what has been done in something easier to include in the release notes than the mailing lists.
> So I will copy some info from the mailing list to this issue:
> On 1/29/07, Xavier Hanin <xa...@gmail.com> wrote:
> Main focus:
>     + 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.