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

Xavier Hanin commented on IVY-434:
----------------------------------

In a second step I've begun to split the Ivy class. I've extracted an
IvySettings class, which stores all settings, i.e. the result of a
call to configure. I've tried to replace some dependencies on the Ivy
class by dependencies on IvySettings, when it was possible, to attempt
to remove some circular dependencies.

For instance:
Ivy -> ModuleDescriptorParser -> Ivy
 is now
Ivy -> ModuleDescriptorParser -> IvySettings

I've also extracted a class ResolveEngine, which is responsible of the
resolve algorithm. Hence the Ivy class has slimmed, but I still have
to extract other parts (retrieve, install, ...) so that it will only
be a Facade to other engines/services.

One thing which has changed due to this split is the way an Ivy
instance is obtained. For the moment when you use a 'new', the
instance created does not create its dependencies (instance of
IvySettings and ResolveEngine for example). The idea is to make it
possible to use other implementations (well, subclasses, since they
are not interfaces) instead of the implementation provided by Ivy, to
be able to fully customize the behaviour of Ivy by feature. So the
creation of dependencies is only done in method I've called 'bind'. If
you want an instance of Ivy already bound to its dependencies, you can
use Ivy.newInstance(). If you prefer to setup the dependencies
yourself, you can call 'new Ivy()' and then setters for the
dependencies. Note that binding is automatically done when you call a
method on Ivy which require a dependency, so that you don't have to
care about that in most cases.

> 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
>             Fix For: 1.5
>
>
> 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 <[EMAIL PROTECTED]> 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.

Reply via email to