Concerning YAGNI: I have rather concrete ideas, how to use the provider framework. Imagine a provider that searches the users home directory for additional module definitions (e.g. /usr/huegen/projectname/hivemodule.xml).
A developer could use this 'personal' module for overriding configurations (e.g. change hostnames and ports), define interceptors, switch service implementations to mock objects etc.
These settings are developer and machine specific and shouldn't reside in the version controlled project path.
Achim Huegen
James Carman wrote:
What if we added a method to RegistryBuilder like this...
class RegistryBuilder { public void addModuleProvider( ModuleProvider provider ); public void constructRegistry( Locale locale ); public static void constructDefaultRegistry(); }
This would avoid having to come up with an AggregateModuleProvider class
(although one could be provided too). I would also recommend changing the
name of ModuleProvider to ModuleDescriptorProvider, since that's what it
really provides and there IS actually a Module class.
As for the YAGNI of this parser/provider framework, I don't know how I feel about that one. I don't know if it'll ever be NEEDED, but it isn't too tough to implement (you'll love how I cram my naming convention suggestion down your throats here too)...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
