You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Claude Brisson <cl...@renegat.net.INVALID> on 2019/06/11 11:32:59 UTC
Merging of VELOCITY-917
FYI, I'm about to merge the parser_experiments branch, see
https://issues.apache.org/jira/browse/VELOCITY-917
and
https://github.com/apache/velocity-engine/compare/parser_experiments .
What it does:
- introduce a Parser interface and patch the javacc generated files so
that the generated parser implements this interface
- templatize the grammar file with maven properties for potential
substitutions of the following characters: $, *, #, @
- introduce a new 'parser.class' Velocity property which can be used to
plug in a custom parser
- provide a new velocity-custom-parser-example module, which
demonstrates how to generate a custom parser
We could certainly go further in the customization, but it's a start.
--
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging of VELOCITY-917
Posted by Michael Osipov <mi...@apache.org>.
Am 2019-06-17 um 16:23 schrieb Claude Brisson:
> Thanks a lot for your review, Michael.
>
> I think I have handled all the points you raised, except otherwise noted.
>
> > I don't like the fast that in several classes the to-be-replaced
> symbols still appear, e.g., RuntimeInstance
>
> The RuntimeService now only exposes a getParserConfiguration() method.
>
> > Since you successfully abstracted from the tokens, I don't see reason
> to still call them by name, .e.g., char.dollar. I would call them by
> function -- even it makes it a bit longer, it is more descriptive. I
> hope you get the point.
>
> Outside the parser, getting a specific char is done with :
>
> runtimeServices.getParserConfiguration().getDollarChar()
>
> Inside the parser, I'm fine with parser.dollar field access. It's not
> exposed to the user, and at least I'm certain to minimize the overhead.
>
> > + <artifactId>maven-bundle-plugin</artifactId>
> > Why do we need this on an example?
>
> Because otherwise, I get:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.1.1:jar (default-jar) on
> project velocity-custom-parser-example: Error assembling JAR: Manifest
> file:
> /home/claude/Projects/velocity/engine/parser/velocity-custom-parser-example/target/classes/META-INF/MANIFEST.MF
> does not exist.
>
> It does so even if I try to have maven-jar-plugin skip parent
> configuration.
Thank you Claude, I will review again by the end of the week.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging of VELOCITY-917
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
Thanks a lot for your review, Michael.
I think I have handled all the points you raised, except otherwise noted.
> I don't like the fast that in several classes the to-be-replaced
symbols still appear, e.g., RuntimeInstance
The RuntimeService now only exposes a getParserConfiguration() method.
> Since you successfully abstracted from the tokens, I don't see reason
to still call them by name, .e.g., char.dollar. I would call them by
function -- even it makes it a bit longer, it is more descriptive. I
hope you get the point.
Outside the parser, getting a specific char is done with :
runtimeServices.getParserConfiguration().getDollarChar()
Inside the parser, I'm fine with parser.dollar field access. It's not
exposed to the user, and at least I'm certain to minimize the overhead.
> + <artifactId>maven-bundle-plugin</artifactId>
> Why do we need this on an example?
Because otherwise, I get:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-jar-plugin:3.1.1:jar (default-jar) on
project velocity-custom-parser-example: Error assembling JAR: Manifest
file:
/home/claude/Projects/velocity/engine/parser/velocity-custom-parser-example/target/classes/META-INF/MANIFEST.MF
does not exist.
It does so even if I try to have maven-jar-plugin skip parent configuration.
--
Claude
On 11/06/2019 16:51, Claude Brisson wrote:
> Of course !
>
> On 11/06/2019 15:09, Michael Osipov wrote:
>> Am 2019-06-11 um 13:32 schrieb Claude Brisson:
>>> FYI, I'm about to merge the parser_experiments branch, see
>>>
>>> https://issues.apache.org/jira/browse/VELOCITY-917
>>>
>>> and
>>>
>>> https://github.com/apache/velocity-engine/compare/parser_experiments .
>>>
>>> What it does:
>>>
>>> - introduce a Parser interface and patch the javacc generated files
>>> so that the generated parser implements this interface
>>> - templatize the grammar file with maven properties for potential
>>> substitutions of the following characters: $, *, #, @
>>> - introduce a new 'parser.class' Velocity property which can be used
>>> to plug in a custom parser
>>> - provide a new velocity-custom-parser-example module, which
>>> demonstrates how to generate a custom parser
>>>
>>> We could certainly go further in the customization, but it's a start.
>>
>> I'd like to review your changes. Can you give a a day or two for this?
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging of VELOCITY-917
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
Of course !
On 11/06/2019 15:09, Michael Osipov wrote:
> Am 2019-06-11 um 13:32 schrieb Claude Brisson:
>> FYI, I'm about to merge the parser_experiments branch, see
>>
>> https://issues.apache.org/jira/browse/VELOCITY-917
>>
>> and
>>
>> https://github.com/apache/velocity-engine/compare/parser_experiments .
>>
>> What it does:
>>
>> - introduce a Parser interface and patch the javacc generated files
>> so that the generated parser implements this interface
>> - templatize the grammar file with maven properties for potential
>> substitutions of the following characters: $, *, #, @
>> - introduce a new 'parser.class' Velocity property which can be used
>> to plug in a custom parser
>> - provide a new velocity-custom-parser-example module, which
>> demonstrates how to generate a custom parser
>>
>> We could certainly go further in the customization, but it's a start.
>
> I'd like to review your changes. Can you give a a day or two for this?
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging of VELOCITY-917
Posted by Michael Osipov <mi...@apache.org>.
Am 2019-06-11 um 13:32 schrieb Claude Brisson:
> FYI, I'm about to merge the parser_experiments branch, see
>
> https://issues.apache.org/jira/browse/VELOCITY-917
>
> and
>
> https://github.com/apache/velocity-engine/compare/parser_experiments .
>
> What it does:
>
> - introduce a Parser interface and patch the javacc generated files so
> that the generated parser implements this interface
> - templatize the grammar file with maven properties for potential
> substitutions of the following characters: $, *, #, @
> - introduce a new 'parser.class' Velocity property which can be used to
> plug in a custom parser
> - provide a new velocity-custom-parser-example module, which
> demonstrates how to generate a custom parser
>
> We could certainly go further in the customization, but it's a start.
I'd like to review your changes. Can you give a a day or two for this?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org