[ https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859339#comment-16859339 ]
Claude Brisson commented on VELOCITY-917: ----------------------------------------- Right now, in the parser_experiments branch, a use can already build a custom parser with the velocity-engine-core module, by customizing the parser maven properties: {noformat} <!-- You can modify those properties to build a custom parser. The parser.name property will be used to generate the class: org.apache.velocity.runtime.parser.${parser.name}Parser which you must specify at runtime using the parser.class Velocity property. You'll have to skip the tests which for now don't work for custom parsers: mvn -DskipTests package and extract the parser class from the generated jar if you wish this custom parser to coexist with the standard one. --> <parser.debug>false</parser.debug> <parser.name>Standard</parser.name> <parser.char.asterisk>*</parser.char.asterisk> <parser.char.at>@</parser.char.at> <parser.char.dollar>$</parser.char.dollar> <parser.char.hash>#</parser.char.hash> {noformat} It's even dangerous per se, because if the user uses the generated jar, it may poison legitimate standard Velocity parsers elswhere. I started a custom plugin, but it's an empty shell. It should expose the same properties in its configuration, and then (both in generate-sources phase) : + filter-remote-copy the resource file {{org/apache/velocity/runtime/parser/Parser.jjt}} towards {{target/parser}} + launch javacc on this file to generate the final org.apache.velocity.runtime.parser.${parser.name}Parser class I'm not familiar with Groovy or Groovy Maven Plugin. > VTL Grammar Characters Configuration > ------------------------------------ > > Key: VELOCITY-917 > URL: https://issues.apache.org/jira/browse/VELOCITY-917 > Project: Velocity > Issue Type: New Feature > Components: Engine > Affects Versions: 2.2 > Reporter: Claude Brisson > Assignee: Claude Brisson > Priority: Major > > Experimental feature. > The goal is to introduce new configuration parameters to be able to change > the VTL grammar. For instance: > parser.character.dollar = '~' > parser.character.hash = '@' > parser.character.arobase = '%' > parser.character.star = '?' > Requirements: > + fully B.C. > + done at runtime, without the need to recompile the parser > + null impact on performance > Implementation: > 1. Parametrize code that needs explicit references to those characters > 2. Define a ParserTokenManager interface and have the parser use this > interface rather than a concrete class > 3. Use a custom class loader to *patch* the concrete token manager .class > file, instantiate this custom token manager and initialize parsers with it > The binary patch is prepared at compilation time (there will be one patch per > JRE vendor and class file version). > Due to the limited capability of this technique, the chosen characters are > restricted to UTF-8 single bytes characters. Patches _could_ be prepared for > two-bytes or more characters, but there would be the need to have as many > parser objects as variants in one/two/... characters combinations. > Also, some characters and combinations are obviously invalid. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org