Hi devs, In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context). The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that. I can see several general rules: 1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext) 2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs. 3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity. There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding If think the best is 4) for now.

Hi devs, In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context). The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that. I can see several general rules: 1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext) 2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs. 3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity. There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding If think the best is 4) for now. WDYT ?

Hi devs, In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context). The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.

I can see several general rules: 1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext) 2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs. 3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity. There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding If think the best is 4) for now. WDYT ? -- Thomas Mortagne

Hi devs, In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context). The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that. I can see several general rules: 1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext) 2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs. 3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity. There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding If think the best is 4) for now. WDYT ? -- Thomas Mortagne