Re: [configuration] [collections] ExtendedProperties
Actually ExtendedProperties isn't even used in [configuration], there are just a method getConfiguration(ExtendedProperties) and a method getExtendedProperties(Configuration) in ConfigurationConverter to maintain compatibility with older code using ExtendedProperties. I'd suggest to deprecate it in favor of Configuration and let it in [collection]. Emmanuel Bourg Stephen Colebourne wrote: [collections] currently has an ExtendedProperties class. IIRC, this class forms part of the [configuration] project. I've never thought it fitted in [collections]. Now [configuration] is promoted, is it time to deprecate the [collections] version??? Basically, I'm trying to kick out all inappropriate classes from [collections]. Stephen - 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] [collections] ExtendedProperties
Deprecate from both? :) Hen On Mon, 29 Dec 2003, Emmanuel Bourg wrote: Actually ExtendedProperties isn't even used in [configuration], there are just a method getConfiguration(ExtendedProperties) and a method getExtendedProperties(Configuration) in ConfigurationConverter to maintain compatibility with older code using ExtendedProperties. I'd suggest to deprecate it in favor of Configuration and let it in [collection]. Emmanuel Bourg Stephen Colebourne wrote: [collections] currently has an ExtendedProperties class. IIRC, this class forms part of the [configuration] project. I've never thought it fitted in [collections]. Now [configuration] is promoted, is it time to deprecate the [collections] version??? Basically, I'm trying to kick out all inappropriate classes from [collections]. Stephen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] [collections] ExtendedProperties
Howdy, Deprecate from both if it's not used. Keep it in Collections if it's used only there, and deprecate the Configuration references to it (unless we have a use-case for Collections depending on Configuration). Yoav Shapira Millennium ChemInformatics -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 8:22 AM To: Jakarta Commons Developers List Subject: Re: [configuration] [collections] ExtendedProperties Deprecate from both? :) Hen On Mon, 29 Dec 2003, Emmanuel Bourg wrote: Actually ExtendedProperties isn't even used in [configuration], there are just a method getConfiguration(ExtendedProperties) and a method getExtendedProperties(Configuration) in ConfigurationConverter to maintain compatibility with older code using ExtendedProperties. I'd suggest to deprecate it in favor of Configuration and let it in [collection]. Emmanuel Bourg Stephen Colebourne wrote: [collections] currently has an ExtendedProperties class. IIRC, this class forms part of the [configuration] project. I've never thought it fitted in [collections]. Now [configuration] is promoted, is it time to deprecate the [collections] version??? Basically, I'm trying to kick out all inappropriate classes from [collections]. Stephen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] [collections] ExtendedProperties
[collections] has no need for ExtendedProperties, and will not be depending on [configuration]. My question is whether [configuration] is more complex to use than ExtendedProperties. If there is no single equivalent class, then I'm not sure I can deprecate in [collections]. Stephen - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] Howdy, Deprecate from both if it's not used. Keep it in Collections if it's used only there, and deprecate the Configuration references to it (unless we have a use-case for Collections depending on Configuration). Yoav Shapira Millennium ChemInformatics -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 8:22 AM To: Jakarta Commons Developers List Subject: Re: [configuration] [collections] ExtendedProperties Deprecate from both? :) Hen On Mon, 29 Dec 2003, Emmanuel Bourg wrote: Actually ExtendedProperties isn't even used in [configuration], there are just a method getConfiguration(ExtendedProperties) and a method getExtendedProperties(Configuration) in ConfigurationConverter to maintain compatibility with older code using ExtendedProperties. I'd suggest to deprecate it in favor of Configuration and let it in [collection]. Emmanuel Bourg Stephen Colebourne wrote: [collections] currently has an ExtendedProperties class. IIRC, this class forms part of the [configuration] project. I've never thought it fitted in [collections]. Now [configuration] is promoted, is it time to deprecate the [collections] version??? Basically, I'm trying to kick out all inappropriate classes from [collections]. Stephen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] [collections] ExtendedProperties
Stephen Colebourne wrote: My question is whether [configuration] is more complex to use than ExtendedProperties. If there is no single equivalent class, then I'm not sure I can deprecate in [collections]. An ExtendedProperties can be easily replaced with a PropertiesConfiguration, it has the same features (includes, arrays of values), the same constructors, and almost the same methods. http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/ExtendedProperties.html http://jakarta.apache.org/commons/configuration/apidocs/org/apache/commons/configuration/PropertiesConfiguration.html Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] [collections] ExtendedProperties
The biggest difference seems to be the lack of a public void save(OutputStream output, String Header) Any particular reason why it was removed? Could it be put back? Stephen - Original Message - From: Emmanuel Bourg [EMAIL PROTECTED] An ExtendedProperties can be easily replaced with a PropertiesConfiguration, it has the same features (includes, arrays of values), the same constructors, and almost the same methods. http://jakarta.apache.org/commons/collections/api/org/apache/commons/collect ions/ExtendedProperties.html http://jakarta.apache.org/commons/configuration/apidocs/org/apache/commons/c onfiguration/PropertiesConfiguration.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] [collections] ExtendedProperties
Stephen Colebourne wrote: The biggest difference seems to be the lack of a public void save(OutputStream output, String Header) Any particular reason why it was removed? Could it be put back? Stephen I don't know but it seems the first version of the save method in BasePropertiesConfiguration wasn't copied from ExtendedProperties, the code is quite different. Arrays of values are saved on the same line, coma separated, in BasePropertiesConfiguration whereas ExtendedProperties save them on multiple lines. I think we might add a flag to select the prefered format to save multiple values. The other big difference is that ExtendedProperties extends Hashtable, so it implements java.util.Map, but Configuration doesn't. I suggested to make Configuration extend Map, this might be an additional argument to do this change. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] [collections] ExtendedProperties
[collections] currently has an ExtendedProperties class. IIRC, this class forms part of the [configuration] project. I've never thought it fitted in [collections]. Now [configuration] is promoted, is it time to deprecate the [collections] version??? Basically, I'm trying to kick out all inappropriate classes from [collections]. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
