RE: [configuration] Cutting a 1.0 Release Help Needed
Eric Pugh wrote on Monday, March 29, 2004 10:57 AM: Ok, I just went back and reread the posts.. Basically what you want is to refactor the HierarchicalDOM4JConfiguration into AbstractHierarchicalConfiguration and then have HierarchicalDOM4JConfiguration and HierarchicalDOMConfiguration. Well, here http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27498 I just have the additional classes for basic DOM support (inkl. unit tests). Any refactoring I would also see post 1.0. You then would retrofit the ConfigurationFactory to support a dom as well as a dom4j element? Well, if it is just for DOM support it is a one liner. Personally I would break up the ConfigurationFactory into a more pluggable approach, but this can also wait post 1.0. Is this correct? If you verify that this won't break 1.3 compatiblity (which I guess it won't..?) and can send in a patch ASAP with some doc fixes and unit tests, then I'll hold up the release. I definitly would want to document the differences between dom and dom4j... IMHO we just have to decide, if we should add this single line in ConfigurationFactory for 1.0 or not. This would imply a dependency on xml-apis for JDK 1.3 ... therefore I did not add it in first line. And since the ConfigurationFactory did also not support the DB based config at the moment, I would just add the files from the patch. Then we have 1.0 with DOM4J as default, but anyone can use JDK 1.4 DOM (although currently not with the ConfigurfationFactory) if he likes to (as it is done with DB config). For post 1.1 I would refactor the factory as already proposed some time ago and then we have support for any kind of configuration technology, but only with the implied depenencies a user really wants to have. Any idea how long it will take you to get this done? Otherwise we can cut 1.0, and then, as soon as you get your code in, either cut 1.0.1 or just cut a snapshot for you. So my proposal: Add 27498 and release 1.0 and do any further refactoring later. But do me another favour: Remove this cruft from the commons-configuration-x.y.jar, that is collected in the root of the archive. I have a modified project.xml at home, that avoids this. I'll create an issue this evening (~ 8h from now) if you like. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Cutting a 1.0 Release Help Needed
Jörg, I think wat you have proposed is a good compromise.. We'll leave configurationfactory alone so as not to create a dependency on the apis for jdk1.3, and if you can get me that patch, I'll do it all tomarrow morning. then, as part of 1.1, doing the refactoring on ConfigurationFactory will be great.. Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 9:42 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [configuration] Cutting a 1.0 Release Help Needed Eric Pugh wrote on Monday, March 29, 2004 10:57 AM: Ok, I just went back and reread the posts.. Basically what you want is to refactor the HierarchicalDOM4JConfiguration into AbstractHierarchicalConfiguration and then have HierarchicalDOM4JConfiguration and HierarchicalDOMConfiguration. Well, here http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27498 I just have the additional classes for basic DOM support (inkl. unit tests). Any refactoring I would also see post 1.0. You then would retrofit the ConfigurationFactory to support a dom as well as a dom4j element? Well, if it is just for DOM support it is a one liner. Personally I would break up the ConfigurationFactory into a more pluggable approach, but this can also wait post 1.0. Is this correct? If you verify that this won't break 1.3 compatiblity (which I guess it won't..?) and can send in a patch ASAP with some doc fixes and unit tests, then I'll hold up the release. I definitly would want to document the differences between dom and dom4j... IMHO we just have to decide, if we should add this single line in ConfigurationFactory for 1.0 or not. This would imply a dependency on xml-apis for JDK 1.3 ... therefore I did not add it in first line. And since the ConfigurationFactory did also not support the DB based config at the moment, I would just add the files from the patch. Then we have 1.0 with DOM4J as default, but anyone can use JDK 1.4 DOM (although currently not with the ConfigurfationFactory) if he likes to (as it is done with DB config). For post 1.1 I would refactor the factory as already proposed some time ago and then we have support for any kind of configuration technology, but only with the implied depenencies a user really wants to have. Any idea how long it will take you to get this done? Otherwise we can cut 1.0, and then, as soon as you get your code in, either cut 1.0.1 or just cut a snapshot for you. So my proposal: Add 27498 and release 1.0 and do any further refactoring later. But do me another favour: Remove this cruft from the commons-configuration-x.y.jar, that is collected in the root of the archive. I have a modified project.xml at home, that avoids this. I'll create an issue this evening (~ 8h from now) if you like. Regards, Jörg - 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] Cutting a 1.0 Release Help Needed
Eric Pugh wrote on Monday, March 29, 2004 12:58 PM: Jörg, I think wat you have proposed is a good compromise.. We'll leave configurationfactory alone so as not to create a dependency on the apis for jdk1.3, and if you can get me that patch, I'll do it all tomarrow morning. Fine, sounds great. I assume your reference for the patch was related to my project.xml issue ... the other one is in Bugzilla. then, as part of 1.1, doing the refactoring on ConfigurationFactory will be great.. Definately. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Cutting a 1.0 Release Help Needed
Hi all, In response to a large number of posts I have recieved both on the mailing list and privately regarding when Commons Configuration 1.0 will be released, I have gone ahead and applied the last of the patches for bugs and I would like to cut the RC1 for Commons Configuration. The remaining issues in BugZilla are all enhancements or refactorings and should be applied post 1.0. At this point I am somewhat stuck at the checksum creation stage. I followed the directions from this document: http://jakarta.apache.org/commons/releases/release.html for steps 1 through 3. However, because Configuration is Maven based, when I run 'maven dist' SSH'ed into jakarta.apache.org I get an error about maven not existing. Ant works, however it tanks on the junit task. Do I need to do steps 4,5,6 SSH'ed in, or can I do them locally and update the results? I have placed some candidates at http://jakarta.apache.org/~epugh/builds/. If the Release Candidate 1 files look good to people, then I will follow the steps here: http://jakarta.apache.org/commons/releases/release.html to cut the 1.0 release. However, I am on winxp, and haven't followed the process of creating md5 checksum's etc.. However, if some other kind soul wishes to play the Release Manager role, I'd be much obliged to them. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Cutting a 1.0 Release Help Needed
Eric Pugh wrote: Hi all, In response to a large number of posts I have recieved both on the mailing list and privately regarding when Commons Configuration 1.0 will be released, I have gone ahead and applied the last of the patches for bugs and I would like to cut the RC1 for Commons Configuration. Does that mean, the DOM JDK 1.4 support is not included in 1.0 ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Cutting a 1.0 Release Help Needed
To my mind, yes... I know that at least one objection was raised, and instead of stalling or rushing a decision, I'd rather delay it.. There is nothing that says that 1.1 has to take 6 months to release or anything like that! I would rather have a 1.0 go out, followed in a month by a 1.1. It would give us a chance to demonstrate to the community that we are actively releaseing.. What's the motto? Release often Release early? Eric -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Jörg Schaible Sent: Sunday, March 28, 2004 5:59 PM To: [EMAIL PROTECTED] Subject: Re: [configuration] Cutting a 1.0 Release Help Needed Eric Pugh wrote: Hi all, In response to a large number of posts I have recieved both on the mailing list and privately regarding when Commons Configuration 1.0 will be released, I have gone ahead and applied the last of the patches for bugs and I would like to cut the RC1 for Commons Configuration. Does that mean, the DOM JDK 1.4 support is not included in 1.0 ? Regards, Jörg - 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] Cutting a 1.0 Release Help Needed
What about enhancements which have been submitted to the bug tracker? Will those get in? -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Sunday, March 28, 2004 12:29 PM To: Commons-Dev Subject: [configuration] Cutting a 1.0 Release Help Needed Hi all, In response to a large number of posts I have recieved both on the mailing list and privately regarding when Commons Configuration 1.0 will be released, I have gone ahead and applied the last of the patches for bugs and I would like to cut the RC1 for Commons Configuration. The remaining issues in BugZilla are all enhancements or refactorings and should be applied post 1.0. At this point I am somewhat stuck at the checksum creation stage. I followed the directions from this document: http://jakarta.apache.org/commons/releases/release.html for steps 1 through 3. However, because Configuration is Maven based, when I run 'maven dist' SSH'ed into jakarta.apache.org I get an error about maven not existing. Ant works, however it tanks on the junit task. Do I need to do steps 4,5,6 SSH'ed in, or can I do them locally and update the results? I have placed some candidates at http://jakarta.apache.org/~epugh/builds/. If the Release Candidate 1 files look good to people, then I will follow the steps here: http://jakarta.apache.org/commons/releases/release.html to cut the 1.0 release. However, I am on winxp, and haven't followed the process of creating md5 checksum's etc.. However, if some other kind soul wishes to play the Release Manager role, I'd be much obliged to them. Eric - 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]
