Am 15.08.2011 23:02, schrieb Ralph Goers:
I don't know. I think it really needs a refactoring. We always said that all
configurations should be based on HierarchicalConfiguration but that still
hasn't happened. Attribute splitting and delimiter parsing have been a pain.
I think it would be great to start with clean interfaces and then implement
from that by refactoring or rewriting as necessary.
Ralph
On the long run there is certainly the need for a refactoring. My
worries are that this will take again some years before the next release
version is ready. So maybe it serves our users better to have an
intermediate version which is not that much different from the current
version, but is compatible with Java 1.5 and the newer commons components.
+1 to the approach of starting with clean interfaces, and the delimiter
parsing stuff is also on top of my list of things to change.
About the "all configurations are hierarchical" concept I am not sure
any more. I fear that this would slow down access to configuration data
(tree-like access vs map access) while there is not much benefit because
more sophisticated queries do not make much sense if the data lacks
structure. But I am open for discussion.
Oliver
On Aug 15, 2011, at 12:39 PM, Oliver Heger wrote:
Am 14.08.2011 23:28, schrieb Emmanuel Bourg:
Le 13/08/2011 20:53, Oliver Heger a écrit :
Hi,
as you may have noticed, I have started some work in order to prepare a
release (version 1.7) of [configuration]. I assume this will be the last
release compatible with Java 1.4.
So the release after 1.7 would be the code on the 2.0 branch ?
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.
I plan to have a look at the current Jira issues, but I hope there are
no major issues open which have to be addressed immediately.
If possible I'd like to get CONFIGURATION-427 addressed in the 1.7
release. If it's ok to store a list of values inside a node I suggest
applying my patch without the new method in ConfigurationNode to
preserve the binary compatibility.
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?
The main open point is still the snapshot dependency to [vfs]. What is
the status there? IMHO it is also an option to create a release branch,
remove the dependency there, and release 1.7 without [vfs] support. It
is no problem to push out another release as soon as [vfs] 2.0 becomes
available. WDYT?
I would release 1.7 without vfs 2.0, we can still release 1.8 later when
vfs is ready.
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.
Oliver
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
