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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Reply via email to