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
