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 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
