Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Am 2017-01-26 um 04:39 schrieb Claude Brisson:
> A new test build of Velocity Engine 2.0 is available (RC6).
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> Velocity Engine 2.0 has been made, and at this time it is simply a "test
> build". We welcome any comments you may have, and will take all feedback
> into account if a quality vote is called for this build.
>
> Release notes:
>
> *
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/release-notes.html
>
>
> Distribution:
>
>  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
> Maven 2 staging repository:
>
>  *
> https://repository.apache.org/content/repositories/orgapachevelocity-1016/
>
> A vote regarding the quality of this test build will be initiated within
> the next couple of days.

Hi Claude,

first of all, great improvement. Just checked the diff and have a few 
comments:

* Left a bunch of comments on the commits on GitHub, have a look
* StringUtils#EOL is never used
* StringUtils#normalizePath() can likely be replaced with Common IO's 
FilenameUtils#normalize()
* StringUtils#nullTrim() can be replaced with Commons Lang's 
StringUtils#trim()
* StringUtils#trimStrings() can be disposed altogether because it 
iterates the list and it is iterated right after the call again. Use 
StringUtils#trim() during the real iteration directly
* OSGi metadata are gone from Core, no Bundle-SymbolicName, no Exports, 
everything is gone from MANIFEST.MF
* There are several spots where collections are iterated with a for loop 
with a counter and #get(i) or a literal (legacy code). This should 
generally be avoided. One example has been commented on GitHub.
* Terrific improvement on the JavaCC code generation!
* JavaCC tells me:
> Note: UNICODE_INPUT option is specified. Please make sure you create the parser/lexer using a Reader with the correct character encoding.
> Warning: Choice conflict in [...] construct at line 1325, column 21.
>          Expansion nested within construct and expansion following construct
>          have common prefixes, one of which is: <TEXT>
>          Consider using a lookahead of 2 or more for nested expansion.
> Warning: Choice conflict in (...)* construct at line 2157, column 5.
>          Expansion nested within construct and expansion following construct
>          have common prefixes, one of which is: <WHITESPACE>
>          Consider using a lookahead of 2 or more for nested expansion.

Is this something one needs to take care of?


Michael