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
|