Wolfgang Hoschek wrote:
> BTW, please don't deprecate ExtendedProperties and refer people to
> future Commons-Configuration.
> The Commons-Configuration complexity and their dependencies are a big
> big mess for someone who simply and conveniently wants to read in some
> configuration values. ExtendedProperties is ideal for such purposes: It
> does the job in a single class and has zero dependencies.
PropertiesConfiguration is no more complex than ExtendedProperties actually, the usage is quite similar if you decide not to use the ConfigurationFactory. In this case the dependencies are minimal, PropertiesConfiguration only relies on [collections] which you already use and [lang] which is a really basic and common dependency. Is this too much ?
Yes, it is too much!!
Many people just want to read some configuration values in an expressive, convenient and straightforward manner, with as little dependencies as possible (read: zero dependencies). java.util.Properties is handy because it has zero dependencies (unfortunately it is not expressive enough, which is why we are talking). So folks are looking for something similar and ExtendedProperties meets just that.
Consider writing a container or client side framework: Why impose auxiliary and unnecessary dependencies and versions on third-party users, or create additional mess with classloader issues? Just pull out ExtendedProperties from commons-collections, rename class to xyz.MyExtendedProperties (keeping copyright and license) and all works fine without any hassle.
(In general, a problem with many smallish commons-xyz modules is that for the comparatively little value they provide, they have frighteningly many cross-dependencies. So one gains some value at the cost of dependency and version hell, with overall may not be worth it)
I think I'll document what package is required for each configuration type, I admit the dependency page generated by Maven is quite frightening currently :)
Wolfgang, I tend to agree, and we do see the version hell as a big issue. There have been and are efforts to reduce the dependency between commons components.
If ExtendedProperties is a valuable collections object and is being used, why should it (one class) be deprecated in favor of Configuration which is a more complex framework? I would assume deprecation could possibly occur if Configuration became the standard for reading properties files and was less "version" dependent. But deprecation probably doesn't make sense until that did occur. Don't throw the bathwater out before you wash the baby...
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
