(sorry if this is a duplicate, I was not sure if I was still registered and could not find my first mail in the archive so I re-registered and sent again)
Hi devs, At XWiki we started working on Velocity 2 upgrade. You can see the work in progress in https://github.com/xwiki/xwiki-commons/tree/feature-velocity2/xwiki-commons-core/xwiki-commons-velocity. Good news first: the refactoring around macro/namespace handling with the new Template class is great for us (especially regarding caching of templates) :) This involved a lot of changes in the API but we can live with it since extensions are not really supposed to manipulate Velocity API directly. Unfortunately we have a few important issues in the context of XWiki since most extensions use Velocity scripts so we tend to be extra careful about retro compatibility to not break all extensions just because you upgrade XWiki: 1. Blockers The change in the way to handle macro parameters cause a major regression for various scripts. Among other things we currently use the following hack to make macros return stuff: (1) (see (2) for a few examples of how it was used) and this is totally broken in Velocity 2.0. I started working on a setVariable directive to replace the old #setVariable macro and have the same behavior then before to limit the incidence of this change but I have a hard time finding the caller variable name when called from a macro (the last test in (2)). The current code is available on https://github.com/xwiki/xwiki-commons/blob/feature-velocity2/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/internal/directive/SetVariableDirective.java , if you have some suggestions that would be great ! I have a few ideas to cover our return need without using this kind of hack but my only concern right now is retro compatibility. I found a few unplanned (at least not documented) regressions in Velocity 2 VTL: * https://issues.apache.org/jira/browse/VELOCITY-896 * https://issues.apache.org/jira/browse/VELOCITY-897 the last one is breaking quite a few existing scripts with regex in it. 2. Things XWiki cannot really use in Velocity 2.0 after all * the new ConversionHandler is actually too limited for us. I created https://issues.apache.org/jira/browse/VELOCITY-892. Not a big deal, we'll keep using our uberspector but would have been nice to delete a bit of code on our side ;) 1: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/macros.vm#L1177 2: https://github.com/xwiki/xwiki-commons/blob/2f8f8be5149a3b9f62aff24ab0a499df68084656/xwiki-commons-core/xwiki-commons-velocity/src/test/java/org/xwiki/velocity/internal/DefaultVelocityEngineTest.java#L296 Thanks, -- Thomas Mortagne --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org