(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

Reply via email to