commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [commons-collections] [Patch] ExtendedProperties
Date Thu, 17 Jun 2004 18:15:21 GMT
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...


View raw message