If you are going to break compatibility the package names need to be changed.
I really dislike CombinedConfiguration. Having the combined nodes point into other configuration nodes makes reloading fragile which is why it now copies nodes. This means that a DynamicCombinedConfiguration that has a common default node will have as many copies of the default node as there are instances of the CombinedConfiguration. This uses a large amount of memory. I really wish DefaultConfigurationBuilder worked on an AggregateConfiguration, but that isn't designed to support XML. The bottom line is that we should think about the classes and interfaces that are there and create a more rational hierarchy. For example, DefaultConfigurationBuilder should be able to create any kind of combination, which means it should work with an Interface, not a concrete class. I still believe HierarchicalConfiguration should be a base Interface, not a Class. The nonsense with attribute splitting and delimiter parsing needs to go away. Ralph On Sep 7, 2012, at 12:46 PM, Oliver Heger wrote: > Hi all, > > the pom was updated to make 2.0-SNAPSHOT the current development version. > This means we are free to implement major changes without having to enforce > binary backwards compatibility. > > The question is: What are the goals for version 2.0? I would recommend to > define a clear focus so that the next release will not take too long. > Obviously there are already people waiting for a [configuration] version > compatible with [lang3]. > > Some points I have in mind are the following ones: > - Switch to [lang3]. This is the main reason for going to version 2.0 because > this cannot be done in a binary compatible way. > - Improve thread safety and concurrent implementations in general. > - Rework reloading. This is related to the previous point because I think the > tight coupling of the current reloading implementation is one of the root > causes making the implementation of thread-safe configurations so hard. > - Have a look at older Jira tickets which have been postponed because they > would break binary compatibility. > > Any other points, wishes, or opinions? We should discuss the points > separately when it comes to their implementation. > > Oliver > > --------------------------------------------------------------------- > 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
