commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Steps towards next release
Date Tue, 16 Aug 2011 20:27:00 GMT
Am 16.08.2011 10:06, schrieb Emmanuel Bourg:
> Le 15/08/2011 21:39, Oliver Heger a écrit :
>> To be honest, I think the branch is a mess.
>> Maybe [configuration] should follow the road other components have gone
>> before: make the APIs ready for Java 5+, but do only limited
>> refactoring. Ideally, this could even be done in a binary compatible
>> way. However, I am not sure whether binary compatibility can be achieved
>> as we might want to polish some interfaces.
> We can explore how far we can go on the Java 5 path while maintaining
> compatibility. Not sure it'll be a huge benefit though, I don't think
> it'll change the usability of the API dramatically.
>> Feel free to commit. But are you sure there are no undesired side
>> effects? I can imagine that queries won't work as expected if a node
>> contains multiple values. Maybe some tests can be added in this respect?
> I don't know for the queries. I admit that's not something I use or
> need, and I suspect people using Commons Configuration to read plist
> files aren't really interested by this feature.
> There is a fundamental mismatch in the list structures and I'm not sure
> it can be solved. In the XML case lists are stored as adjacent nodes of
> equivalent names. In the plist case a single node must hold all the
> elements.

I am not familiar with the plist format, so I cannot give a qualified 
statement. Just some ideas:

Aren't we free to decide how to represent data structures in a 
configuration? I mean, the dot keys used by XMLConfiguration is also 
just a convention. We could transform a plist file to a XML-friendly 
structure and store it in a hierarchical configuration. We just have to 
document how to access list structures. We could then add specialized 
convenience methods to PListConfiguration for accessing lists in a way 
more intuitive for plist users. Wouldn't this be an option?


>> Probably a question of time. If the vfs 2.0 release is a matter of some
>> days or weeks, this is no problem. The release preparations for
>> [configuration] will take some time, too. However, if we were talking
>> about some more months, I would prefer a release without vfs, too.
> Agree on that
> Emmanuel Bourg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message