On 5/20/07, Gilles Scokart <[EMAIL PROTECTED]> 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/
