That's OK. At least getting agreement on tackling the interfaces first gives us somewhere to start. Then we can debate if or where generics, etc. should be used.
The reason I still prefer to base on the Hierarchical is that the current way of hooking in the File configuration support is just ugly. Ralph On Aug 15, 2011, at 10:52 PM, Oliver Heger wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
