Re: [configuration] New hierarchical configurations
Emmanuel Bourg schrieb: Oliver Heger a écrit : The main reason for the restructuring of the packages was to increase modularity, which is especially important in environments like OSGi where you have fine control over the packages to import. An "all configurations in the main package" approach won't help here. By "increasing modularity" you mean producing several jars, one for each implementation ? Emmanuel Bourg No, at least not at the first step. I simply would like to add more structure to our bunch of classes: lose coupling, cohesion etc. At the moment the library is a whole "blob". Our sub packages do not improve situation because there are cyclic dependencies everywhere. IMO design can be improved here. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : The main reason for the restructuring of the packages was to increase modularity, which is especially important in environments like OSGi where you have fine control over the packages to import. An "all configurations in the main package" approach won't help here. By "increasing modularity" you mean producing several jars, one for each implementation ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Emmanuel Bourg wrote: > Oliver Heger a écrit : > >>> XMLConfiguration and XMLPropertiesConfiguration remain in the main >>> package. >> >> Why? > > > The purpose of the package is to group only the SAX readers as they form > a hierarchy providing a specific feature, just like the BeanUtils bridge > in the beanutils package. I don't know if these classes are frequently > used, actually I don't know the use cases for these readers. As a non > core feature I don't think they deserve to remain in the main package. > > I don't think moving the XMLConfiguration and XMLPropertiesConfiguration > classes in an xml package is necessary, I don't have any problem with > them staying in the main package. Also, that would not make sense to > move them but not XMLPropertyListConfiguration in the plist package, and > having XMLPropertyListConfiguration outside the plist package seems > absurds too. > > Emmanuel Bourg > The main reason for the restructuring of the packages was to increase modularity, which is especially important in environments like OSGi where you have fine control over the packages to import. An "all configurations in the main package" approach won't help here. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : XMLConfiguration and XMLPropertiesConfiguration remain in the main package. Why? The purpose of the package is to group only the SAX readers as they form a hierarchy providing a specific feature, just like the BeanUtils bridge in the beanutils package. I don't know if these classes are frequently used, actually I don't know the use cases for these readers. As a non core feature I don't think they deserve to remain in the main package. I don't think moving the XMLConfiguration and XMLPropertiesConfiguration classes in an xml package is necessary, I don't have any problem with them staying in the main package. Also, that would not make sense to move them but not XMLPropertyListConfiguration in the plist package, and having XMLPropertyListConfiguration outside the plist package seems absurds too. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Emmanuel Bourg schrieb: Oliver Heger a écrit : Would XMLConfiguration also go into this package? XMLConfiguration and XMLPropertiesConfiguration remain in the main package. Why? Oliver In this regard the package name o.a.c.c.sax would make more sense. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : Would XMLConfiguration also go into this package? XMLConfiguration and XMLPropertiesConfiguration remain in the main package. In this regard the package name o.a.c.c.sax would make more sense. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Emmanuel Bourg schrieb: Oliver Heger a écrit : I would like to keep main package pretty small, so that it only contains the basic interfaces and abstract base classes. Sub packages would group classes with similar functionality. The plist and web packages are good examples for that, but I am not sure how to handle specific implementations consisting of only one or two classes (e.g. INIConfiguration). Putting them in their own package probably does not make too much sense. I see a package change that might be worth considering : the 3 XMLReader classes form a group that could be put in a sub package, o.a.c.c.xml or o.a.c.c.sax. What do you think ? Emmanuel Bourg Would XMLConfiguration also go into this package? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : I would like to keep main package pretty small, so that it only contains the basic interfaces and abstract base classes. Sub packages would group classes with similar functionality. The plist and web packages are good examples for that, but I am not sure how to handle specific implementations consisting of only one or two classes (e.g. INIConfiguration). Putting them in their own package probably does not make too much sense. I see a package change that might be worth considering : the 3 XMLReader classes form a group that could be put in a sub package, o.a.c.c.xml or o.a.c.c.sax. What do you think ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : Sub packages would group classes with similar functionality. The plist and web packages are good examples for that, but I am not sure how to handle specific implementations consisting of only one or two classes (e.g. INIConfiguration). Putting them in their own package probably does not make too much sense. I prefer to keep the implementations in the main package, unless they involve a lot of specific classes like the plist and web configurations. An advantage of keeping the classes in the same package is to share internal code with package private classes. For example JavaCC generates several classes that don't have to be exposed to the user and can be made package private. Theses classes could be reused for another parsers. If we implement JSON/YAML/OGDL configuration using JavaCC that may be nice to share these classes, but splitting the implementations in different packages will prevent it. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Emmanuel Bourg schrieb: +1 for removing the old configurations, otherwise that would be confusing for the users. Regarding the package structure do you have other plans besides the 'flat' package ? I would like to keep main package pretty small, so that it only contains the basic interfaces and abstract base classes. Sub packages would group classes with similar functionality. The plist and web packages are good examples for that, but I am not sure how to handle specific implementations consisting of only one or two classes (e.g. INIConfiguration). Putting them in their own package probably does not make too much sense. Oliver Emmanuel Bourg Agreed. After refactoring of the hierarchical file-based configurations is complete, it shows that the new configurations are indeed a full replacement for the old ones: all unit tests are still running. About the naming: If all our configurations are hierarchical (at least this is the plan currently), there does not seem to be much point in calling a concrete implementation "HierarchicalConfiguration". Therefore I used the name "InMemoryConfiguration" for the replacement (because the whole data is stored as ConfigurationNode objects in memory). In the first discussions about the new configuration2 branch somebody suggested using a different package structure, which is more focused on modularity, i.e. there should be packages containing configuration implementations with a specific functionality. I would like to follow this suggestion. Any objections or further comments? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
+1 for removing the old configurations, otherwise that would be confusing for the users. Regarding the package structure do you have other plans besides the 'flat' package ? Emmanuel Bourg Agreed. After refactoring of the hierarchical file-based configurations is complete, it shows that the new configurations are indeed a full replacement for the old ones: all unit tests are still running. About the naming: If all our configurations are hierarchical (at least this is the plan currently), there does not seem to be much point in calling a concrete implementation "HierarchicalConfiguration". Therefore I used the name "InMemoryConfiguration" for the replacement (because the whole data is stored as ConfigurationNode objects in memory). In the first discussions about the new configuration2 branch somebody suggested using a different package structure, which is more focused on modularity, i.e. there should be packages containing configuration implementations with a specific functionality. I would like to follow this suggestion. Any objections or further comments? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] New hierarchical configurations
Oliver Heger wrote: [snip] < about the naming: If all our configurations are hierarchical (at least > this is the plan currently), there does not seem to be much point in > calling a concrete implementation > "HierarchicalConfiguration". Therefore > I used the name "InMemoryConfiguration" for the replacement (because > the whole data is stored as ConfigurationNode objects in memory). +1 > In the first discussions about the new configuration2 branch somebody > suggested using a different package structure, which is more > focused on > modularity, i.e. there should be packages containing configuration > implementations with a specific functionality. I would like to follow > this suggestion. Any objections or further comments? +1 - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Jörg Schaible wrote: > Oliver Heger wrote: > >>I have added new hierarchical configuration implementations >>based on the >>node handler approach. >> >>There is now a new AbstractHierarchicalConfiguration class >>providing basic functionality for dealing with hierarchical >>structures. >> >>Derived from that is InMemoryConfiguration, which is almost equivalent >>to HierarchicalConfiguration. The new SubConfiguration class is the >>counterpart to SubnodeConfiguration. >> >>I copied the tests from the HierarchicalConfiguration, and they run >>successful for the new configuration class. There are minor >>differences in the handling of attributes: I decided not to allow >>multiple values for an attribute as was possible for >>HierarchicalConfiguration as part >>of the list handling functionality. IMO this was rather >>confusing than >>helpful. Obviously these differences are not covered by the >>unit tests. >> >>Next steps are further configuration implementations based on the new >>classes. I will do some experiments with XMLConfiguration and a new >>preferences configuration class. >> >>We can decide how to deal with the old classes. We could completely >>replace them with the new ones or deprecate them only. > > > For a major (incompatible) release 2.0 ... replace them. No need to burden > ourselves with old code maintenance. Get rid of old stuff as soon as possible. > > - Jörg > Agreed. After refactoring of the hierarchical file-based configurations is complete, it shows that the new configurations are indeed a full replacement for the old ones: all unit tests are still running. About the naming: If all our configurations are hierarchical (at least this is the plan currently), there does not seem to be much point in calling a concrete implementation "HierarchicalConfiguration". Therefore I used the name "InMemoryConfiguration" for the replacement (because the whole data is stored as ConfigurationNode objects in memory). In the first discussions about the new configuration2 branch somebody suggested using a different package structure, which is more focused on modularity, i.e. there should be packages containing configuration implementations with a specific functionality. I would like to follow this suggestion. Any objections or further comments? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] New hierarchical configurations
Oliver Heger wrote: > I have added new hierarchical configuration implementations > based on the > node handler approach. > > There is now a new AbstractHierarchicalConfiguration class > providing basic functionality for dealing with hierarchical > structures. > > Derived from that is InMemoryConfiguration, which is almost equivalent > to HierarchicalConfiguration. The new SubConfiguration class is the > counterpart to SubnodeConfiguration. > > I copied the tests from the HierarchicalConfiguration, and they run > successful for the new configuration class. There are minor > differences in the handling of attributes: I decided not to allow > multiple values for an attribute as was possible for > HierarchicalConfiguration as part > of the list handling functionality. IMO this was rather > confusing than > helpful. Obviously these differences are not covered by the > unit tests. > > Next steps are further configuration implementations based on the new > classes. I will do some experiments with XMLConfiguration and a new > preferences configuration class. > > We can decide how to deal with the old classes. We could completely > replace them with the new ones or deprecate them only. For a major (incompatible) release 2.0 ... replace them. No need to burden ourselves with old code maintenance. Get rid of old stuff as soon as possible. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] New hierarchical configurations
I have added new hierarchical configuration implementations based on the node handler approach. There is now a new AbstractHierarchicalConfiguration class providing basic functionality for dealing with hierarchical structures. Derived from that is InMemoryConfiguration, which is almost equivalent to HierarchicalConfiguration. The new SubConfiguration class is the counterpart to SubnodeConfiguration. I copied the tests from the HierarchicalConfiguration, and they run successful for the new configuration class. There are minor differences in the handling of attributes: I decided not to allow multiple values for an attribute as was possible for HierarchicalConfiguration as part of the list handling functionality. IMO this was rather confusing than helpful. Obviously these differences are not covered by the unit tests. Next steps are further configuration implementations based on the new classes. I will do some experiments with XMLConfiguration and a new preferences configuration class. We can decide how to deal with the old classes. We could completely replace them with the new ones or deprecate them only. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
