I think Sebb said he was reviewing... Gary
On Aug 20, 2012, at 7:38, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > Am 19.08.2012 20:00, schrieb Ralph Goers: >> I don't think that is serious enough to warrant another candidate. I plan to >> review RC1 later today. >> >> Ralph >> >> On Aug 19, 2012, at 6:38 AM, Gary Gregory wrote: >> >>> If you change the POM and you want that to be part of the release then >>> you need another RC. In this case, you want a cleaner Clirr report for >>> that release which means that report must be able to be generated from >>> the release tag and sources. At least that's how it seems to me. >>> >>> Gary > > A configuration of the clirr plug-in was added to the pom which excludes > parser classes generated by JavaCC from the clirr report, so the report is > now clear. > > After the release the site for the new snapshot will be deployed, so there > won't be any clirr warnings. > > BTW, 72 hours are passed now, and there are only 2 +1 votes. It would be nice > if somebody did another review! > > Oliver > >>> >>> On Aug 18, 2012, at 11:13, Oliver Heger <oliver.he...@oliver-heger.de> >>> wrote: >>> >>>> Am 17.08.2012 23:58, schrieb sebb: >>>>> On 17 August 2012 21:02, Oliver Heger <oliver.he...@oliver-heger.de> >>>>> wrote: >>>>>> Hi Gary, >>>>>> >>>>>> Am 17.08.2012 21:19, schrieb Gary Gregory: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Are the Clirr warning about constant value changes from 1.8 be an issue >>>>>>> for >>>>>>> existing clients? >>>>>>> Or, are the values only used by [configuration] itself? >>>>>> >>>>>> >>>>>> the constants are only used internally. They belong to the parser for >>>>>> plist >>>>>> configuration files (which is generated by JavaCC) and define its state >>>>>> transition graph. They have changed because the parser now supports >>>>>> comments >>>>>> in configuration files. >>>>> >>>>> If there is a need to add new constants in the future, can JavaCC be >>>>> persuaded to add them at the end? >>>>> This would avoid needless warnings in the Clirr report. >>>>> >>>>> Also, it would help if the release notes explained why the Clirr >>>>> warnings are harmless to forestall any questions by users. >>>> >>>> The affected class is not even part of the code base, it is generated >>>> during the build process. If you have a look at the source code [1], you >>>> will probably agree that it is hardly of any use for client applications. >>>> Therefore, I think writing a warning in the release notes will add more >>>> confusion than it helps. >>>> >>>> Wouldn't it be better then to exclude the class from the Clirr report? >>>> Will have to check whether this is possible. This could be done before >>>> publishing the site for the next SNAPSHOT version and would not require a >>>> new RC, right? >>>> >>>> Oliver >>>> >>>> [1] >>>> http://people.apache.org/~oheger/configuration-1.9rc1/xref/org/apache/commons/configuration/plist/PropertyListParserConstants.html >>>> >>>>> >>>>>> Thanks for the review. >>>>>> Oliver >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> Gary >>>>>>> >>>>>>> On Thu, Aug 16, 2012 at 4:09 PM, Oliver Heger >>>>>>> <oliver.he...@oliver-heger.de>wrote: >>>>>>> >>>>>>>> This is a vote to release Apache Commons Configuration 1.9 based on the >>>>>>>> first release candidate. >>>>>>>> >>>>>>>> Tag: >>>>>>>> http://svn.apache.org/repos/**asf/commons/proper/**configuration/tags/** >>>>>>>> >>>>>>>> CONFIGURATION_1_9RC1/<http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_9RC1/> >>>>>>>> >>>>>>>> Site: >>>>>>>> >>>>>>>> http://people.apache.org/~**oheger/configuration-1.9rc1/<http://people.apache.org/%7Eoheger/configuration-1.9rc1/> >>>>>>>> >>>>>>>> Binaries: >>>>>>>> https://repository.apache.org/**content/repositories/** >>>>>>>> >>>>>>>> orgapachecommons-016/<https://repository.apache.org/content/repositories/orgapachecommons-016/> >>>>>>>> >>>>>>>> [ ] +1 release it >>>>>>>> [ ] +0 go ahead I don't care >>>>>>>> [ ] -1 no, do not release it because >>>>>>>> >>>>>>>> Vote will remain open for at least 72 hours. >>>>>>>> >>>>>>>> Oliver >>>>>>>> >>>>>>>> ------------------------------**------------------------------**--------- >>>>>>>> To unsubscribe, e-mail: >>>>>>>> dev-unsubscribe@commons.**apache.org<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 >>> >> >> >> --------------------------------------------------------------------- >> 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
