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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
