Ivy engines and IvySettings dependencies

[Gilles Scokart <gs...@gmail.com>]

The Engines behind the Ivy class (SortEngine, SearchEngine,
InstallEngine, etc.) are now dependent of the IvySettings.  However,
they usually only need a small part of it.  That makes the use (and
the testing) of the engine a little bit more complex because it is not
clear which part of the settings will be used.

I think it should be better to reduce the dependency between the
Engine and the IvySettings.  I see two aproach to do that:
  1. For each engines we define one or more interface implemented by
the IvySettings, and we use the interface(s) in the engine instead of
the IvySettings directly.
  2. Instead of injecting the IvySetting in the engine, we inject the
'part' of the settings that is required by the engine (expl: a
VersionMatcher, a CircularDependencyStrategy, etc...).  This aproach
is I think cleaner because it doesn't introduce new artefacts, but it
change the life-cycle of the engines that will have to be
recreated/updated when the settings is updated.

WDYT?

-- 
Gilles SCOKART

Re: Ivy engines and IvySettings dependencies

[Xavier Hanin <xa...@gmail.com>]

On 5/20/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> The Engines behind the Ivy class (SortEngine, SearchEngine,
> InstallEngine, etc.) are now dependent of the IvySettings.  However,
> they usually only need a small part of it.  That makes the use (and
> the testing) of the engine a little bit more complex because it is not
> clear which part of the settings will be used.
>
> I think it should be better to reduce the dependency between the
> Engine and the IvySettings.  I see two aproach to do that:
>   1. For each engines we define one or more interface implemented by
> the IvySettings, and we use the interface(s) in the engine instead of
> the IvySettings directly.
>   2. Instead of injecting the IvySetting in the engine, we inject the
> 'part' of the settings that is required by the engine (expl: a
> VersionMatcher, a CircularDependencyStrategy, etc...).  This aproach
> is I think cleaner because it doesn't introduce new artefacts, but it
> change the life-cycle of the engines that will have to be
> recreated/updated when the settings is updated.
>
> WDYT?


I agree that reducing the dependency between engine and settings would be
better. I like the approach #2 for the cleaner architecture it introduces,
with easier unit testing and maintenance. But on the other hand I'm afraid
moving to this code architecture is a very important task, and I'm not sure
it's the best way to spend so much time ATM. Approach #1 is far easier to
implement I think, and already provide a good solution to the problem. So
I'm in favor of approach #1, but more for a time reason than an architecture
one...

Xavier

--
> Gilles SCOKART
>



-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/