commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Hoschek <>
Subject Re: [commons-collections] [Patch] ExtendedProperties
Date Thu, 17 Jun 2004 17:30:27 GMT
> > 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 :)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message