commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@apache.org>
Subject Re: [configuration] What changes in Commons Configuration 2.0 ?
Date Mon, 18 Feb 2008 10:43:25 GMT
Oliver Heger a écrit :

>> - New package name, with no version number please. I suggest 
>> org.apache.commons.config
> I prefer going with the commons standards here. I am against a config 
> package because it is unrelated to the existing configuration package. A 
> package name of configuration2 shows that the API is evolving.

Well, the evolution of the component is mainly materialized by the 
change of the major revision number, not by the package name. Changing 
the package is just a solution to avoid conflicts.

Btw I'm less concerned about the package name than the artifactId.


>> - Should we turn Configuration into an abstract class to allow the 
>> addition of new methods later ?
> Interfaces are fine IMO. For instance, they allow for a better 
> testability using mock objects.

Between additional features and improved testability I'd go for the 
features. Is using a mock for a Configuration actually useful ? It seems 
easier to use a BaseConfiguration directly.


> I am not that happy with the current approach to reloading. Maybe we can 
> come up with something better.

I agree, we need an active reloading mechanism to be able to fire a 
change notification as soon as the file has been touched.


> The current way of dealing with files and file names is complex, and the 
> API is bloated with lots of get and set methods. We have now the chance 
> of changing this. So why not go for locators? This will be a hard break 
> for configuration 1 users, but on the long run I think we are better off.

I think it's important to keep a simple way of instantiating a 
Configuration directly from a File or an URL without using a locator. 
The string based constructors could use a default locator.

Regarding the get/setters I would happily kill the filename and basepath 
accessors.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message