21 Jul
2016
21 Jul
'16
5:26 p.m.
Hi.
I'm currently working on Velocity 2.0 packaging.
If that's OK with you, I would like to incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement
from your part to be able to change its licence to Apache 2.0 (LGPL and
Apache 2.0 licences aren't compatible).
By the way, I take this opportunity to tell you that if there is another
specific part of xwiki-commons-velocity that you think should be
integrated on our side, or an important missing feature you'd like to
insist on, don't hesitate. I already integrated VELOCITY-825, for
instance, so String->Enum constant conversions are now handled by
Velocity. There may be other important conversion cases you'd like to
see handled.
Regards,
Claude
22 Jul
22 Jul
7:45 a.m.
+1 from me.
On 07/21/2016 11:26 AM, Claude Brisson wrote:
Hi.
I'm currently working on Velocity 2.0 packaging.
If that's OK with you, I would like to incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement
from your part to be able to change its licence to Apache 2.0 (LGPL and
Apache 2.0 licences aren't compatible).
By the way, I take this opportunity to tell you that if there is another
specific part of xwiki-commons-velocity that you think should be
integrated on our side, or an important missing feature you'd like to
insist on, don't hesitate. I already integrated VELOCITY-825, for
instance, so String->Enum constant conversions are now handled by
Velocity. There may be other important conversion cases you'd like to
see handled.
Regards,
Claude
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
8:49 a.m.
Hi Claude,
On 21 Jul 2016, at 17:26, Claude Brisson
<claude(a)renegat.net> wrote:
Hi.
I'm currently working on Velocity 2.0 packaging.
If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java
into Velocity, but I need a statement from your part to be able to change its licence to
Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible).
Thanks for reaching out. A big +1 from me too. The more we can move to Velocity the better
it is.
By the way, I take this opportunity to tell you that
if there is another specific part of xwiki-commons-velocity that you think should be
integrated on our side, or an important missing feature you'd like to insist on,
don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum
constant conversions are now handled by Velocity. There may be other important conversion
cases you'd like to see handled.
Ok cool.
On your side, if you see other issues that you’d be willing to integrate let us know.
Thanks
-Vincent
Regards,
Claude
8:58 a.m.
One thing that would be nice to have is the custom whitespace filter
that the {{velocity}} macro has: see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro#HParame…
and
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro+Filter
Basically, Velocity only supports literal whitespace processing, with
every space and newline going into the output, while we like to be able
to indent our sources without padding the output with lots of extra spaces.
On 07/22/2016 02:49 AM, Vincent Massol wrote:
Hi Claude,
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 21 Jul 2016, at 17:26, Claude Brisson
<claude(a)renegat.net> wrote:
Hi.
I'm currently working on Velocity 2.0 packaging.
If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java
into Velocity, but I need a statement from your part to be able to change its licence to
Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible).
Thanks for reaching out. A big +1 from me too. The more we can move to Velocity the
better it is.
By the way, I take this opportunity to tell you
that if there is another specific part of xwiki-commons-velocity that you think should be
integrated on our side, or an important missing feature you'd like to insist on,
don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum
constant conversions are now handled by Velocity. There may be other important conversion
cases you'd like to see handled.
Ok cool.
On your side, if you see other issues that you’d be willing to integrate let us know.
Thanks
-Vincent
> Regards,
>
> Claude
26 Jul
26 Jul
6:50 p.m.
I agree whitespace filtering is a hot topic. I'll check those links, but
I'm not sure I'll be able to provide something for 2.0, though...
Claude
On 22/07/2016 08:58, Sergiu Dumitriu wrote:
One thing that would be nice to have is the custom
whitespace filter
that the {{velocity}} macro has: see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro#HParame…
and
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro+Filter
Basically, Velocity only supports literal whitespace processing, with
every space and newline going into the output, while we like to be able
to indent our sources without padding the output with lots of extra spaces.
On 07/22/2016 02:49 AM, Vincent Massol wrote:
> Hi Claude,
>
>> On 21 Jul 2016, at 17:26, Claude Brisson <claude(a)renegat.net> wrote:
>>
>> Hi.
>>
>> I'm currently working on Velocity 2.0 packaging.
>>
>> If that's OK with you, I would like to incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement from your part to be
able to change its licence to Apache 2.0 (LGPL and Apache 2.0 licences aren't
compatible).
> Thanks for reaching out. A big +1 from me too. The more we can move to Velocity the
better it is.
>
>> By the way, I take this opportunity to tell you that if there is another specific
part of xwiki-commons-velocity that you think should be integrated on our side, or an
important missing feature you'd like to insist on, don't hesitate. I already
integrated VELOCITY-825, for instance, so String->Enum constant conversions are now
handled by Velocity. There may be other important conversion cases you'd like to see
handled.
> Ok cool.
>
> On your side, if you see other issues that you’d be willing to integrate let us
know.
>
> Thanks
> -Vincent
>
>> Regards,
>>
>> Claude
22 Jul
22 Jul
9:52 a.m.
On Thu, Jul 21, 2016 at 5:26 PM, Claude Brisson <claude(a)renegat.net> wrote:
Hi.
I'm currently working on Velocity 2.0 packaging.
Great news :)
If that's OK with you, I would like to incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement from
your part to be able to change its licence to Apache 2.0 (LGPL and Apache
2.0 licences aren't compatible).
+1 for me
By the way, I take this opportunity to tell you that if there is another
specific part of xwiki-commons-velocity that you think should be integrated
on our side, or an important missing feature you'd like to insist on, don't
hesitate. I already integrated VELOCITY-825, for instance, so String->Enum
constant conversions are now handled by Velocity. There may be other
important conversion cases you'd like to see handled.
Note that XWiki goes far beyond String->Enum. When the signature of a
method cannot be found it search for method with similar number of
arguments and use xwiki-commons-properties module (similar to apache
beanutils) to try to convert the parameter it gets into the types of
the method parameters. We are using this a lot so it would probably be
a nice to have in Velocity (probably something based on beanutils that
could be extended on our side to use all xwiki-commons-properties
supported types). See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Maybe it's not the case in Velocity 2.0 anymore, but restriction on
Class methods access is way too strong in 1.7 so we overwritten secure
introspector to accept more calls. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
We implemented a directives based try/catch support for Velocity
recently. We don't use it much yet (too young) but we probably will.
Could be interesting on Velocity side. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Regards,
Claude
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
26 Jul
26 Jul
6:47 p.m.
Thanks for your votes.
Regarding your suggestions:
- velocity 2.0 will also go a little bit further than string -> enum,
as it will try to convert method arguments between all basic Java data
types (boolean, number, string).
- it does this via a pluggable ConversionHandler that can easily be
extended, see [1]
- I've added a public VelMethod.getMethod() getter, so it should be
easier to access methods
[1]
http://velocity.apache.org/engine/devel/developer-guide.html#method-argumen…
Claude
On 22/07/2016 09:52, Thomas Mortagne wrote:
On Thu, Jul 21, 2016 at 5:26 PM, Claude Brisson
<claude(a)renegat.net> wrote:
Hi.
I'm currently working on Velocity 2.0 packaging.
Great news :)
If that's OK with you, I would like to
incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement from
your part to be able to change its licence to Apache 2.0 (LGPL and Apache
2.0 licences aren't compatible).
+1 for me
By the way, I take this opportunity to tell you
that if there is another
specific part of xwiki-commons-velocity that you think should be integrated
on our side, or an important missing feature you'd like to insist on, don't
hesitate. I already integrated VELOCITY-825, for instance, so String->Enum
constant conversions are now handled by Velocity. There may be other
important conversion cases you'd like to see handled.
Note that XWiki goes far
beyond String->Enum. When the signature of a
method cannot be found it search for method with similar number of
arguments and use xwiki-commons-properties module (similar to apache
beanutils) to try to convert the parameter it gets into the types of
the method parameters. We are using this a lot so it would probably be
a nice to have in Velocity (probably something based on beanutils that
could be extended on our side to use all xwiki-commons-properties
supported types). See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Maybe it's not the case in Velocity 2.0 anymore, but restriction on
Class methods access is way too strong in 1.7 so we overwritten secure
introspector to accept more calls. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
We implemented a directives based try/catch support for Velocity
recently. We don't use it much yet (too young) but we probably will.
Could be interesting on Velocity side. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Regards,
Claude
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Jul
28 Jul
10:50 a.m.
Ok great, I added it to http://jira.xwiki.org/browse/XCOMMONS-1027 so
that we don't forget.
On Tue, Jul 26, 2016 at 6:47 PM, Claude Brisson <claude(a)renegat.net> wrote:
Thanks for your votes.
Regarding your suggestions:
- velocity 2.0 will also go a little bit further than string -> enum, as it
will try to convert method arguments between all basic Java data types
(boolean, number, string).
- it does this via a pluggable ConversionHandler that can easily be
extended, see [1]
- I've added a public VelMethod.getMethod() getter, so it should be easier
to access methods
[1]
http://velocity.apache.org/engine/devel/developer-guide.html#method-argumen…
Claude
On 22/07/2016 09:52, Thomas Mortagne wrote:
--
Thomas Mortagne
On Thu, Jul 21, 2016 at 5:26 PM, Claude Brisson <claude(a)renegat.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi.
I'm currently working on Velocity 2.0 packaging.
Great news :)
If that's OK with you, I would like to
incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement
from
your part to be able to change its licence to Apache 2.0 (LGPL and Apache
2.0 licences aren't compatible).
+1 for me
By the way, I take this opportunity to tell you
that if there is another
specific part of xwiki-commons-velocity that you think should be
integrated
on our side, or an important missing feature you'd like to insist on,
don't
hesitate. I already integrated VELOCITY-825, for instance, so
String->Enum
constant conversions are now handled by Velocity. There may be other
important conversion cases you'd like to see handled.
Note that XWiki goes far beyond String->Enum. When the signature of a
method cannot be found it search for method with similar number of
arguments and use xwiki-commons-properties module (similar to apache
beanutils) to try to convert the parameter it gets into the types of
the method parameters. We are using this a lot so it would probably be
a nice to have in Velocity (probably something based on beanutils that
could be extended on our side to use all xwiki-commons-properties
supported types). See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Maybe it's not the case in Velocity 2.0 anymore, but restriction on
Class methods access is way too strong in 1.7 so we overwritten secure
introspector to accept more calls. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
We implemented a directives based try/catch support for Velocity
recently. We don't use it much yet (too young) but we probably will.
Could be interesting on Velocity side. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Regards,
Claude
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Jun
20 Jun
1:13 p.m.
Hi Claude,
I (finally) started working on Velocity 2.0. You can see the work in
progress in
https://github.com/xwiki/xwiki-commons/tree/feature-velocity2/xwiki-commons….
Good news first: the refactoring around macro/namespace handling with
the new Template class is great for us :)
Unfortunately we have a few important issues in the context of XWiki
since most extensions use Velocity and we don't want to break them as
much as possible:
= 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…,
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
= 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/xwi…
2:
https://github.com/xwiki/xwiki-commons/blob/2f8f8be5149a3b9f62aff24ab0a499d…
On Thu, Jul 28, 2016 at 10:50 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Ok great, I added it to
http://jira.xwiki.org/browse/XCOMMONS-1027 so
that we don't forget.
On Tue, Jul 26, 2016 at 6:47 PM, Claude Brisson <claude(a)renegat.net> wrote:
Thanks,
--
Thomas Mortagne
Thanks for your votes.
Regarding your suggestions:
- velocity 2.0 will also go a little bit further than string -> enum, as it
will try to convert method arguments between all basic Java data types
(boolean, number, string).
- it does this via a pluggable ConversionHandler that can easily be
extended, see [1]
- I've added a public VelMethod.getMethod() getter, so it should be easier
to access methods
[1]
http://velocity.apache.org/engine/devel/developer-guide.html#method-argumen…
Claude
On 22/07/2016 09:52, Thomas Mortagne wrote:
--
Thomas Mortagne
On Thu, Jul 21, 2016 at 5:26 PM, Claude Brisson <claude(a)renegat.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi.
I'm currently working on Velocity 2.0 packaging.
Great news :)
If that's OK with you, I would like to
incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement
from
your part to be able to change its licence to Apache 2.0 (LGPL and Apache
2.0 licences aren't compatible).
+1 for me
By the way, I take this opportunity to tell you
that if there is another
specific part of xwiki-commons-velocity that you think should be
integrated
on our side, or an important missing feature you'd like to insist on,
don't
hesitate. I already integrated VELOCITY-825, for instance, so
String->Enum
constant conversions are now handled by Velocity. There may be other
important conversion cases you'd like to see handled.
Note that XWiki goes far beyond String->Enum. When the signature of a
method cannot be found it search for method with similar number of
arguments and use xwiki-commons-properties module (similar to apache
beanutils) to try to convert the parameter it gets into the types of
the method parameters. We are using this a lot so it would probably be
a nice to have in Velocity (probably something based on beanutils that
could be extended on our side to use all xwiki-commons-properties
supported types). See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Maybe it's not the case in Velocity 2.0 anymore, but restriction on
Class methods access is way too strong in 1.7 so we overwritten secure
introspector to accept more calls. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
We implemented a directives based try/catch support for Velocity
recently. We don't use it much yet (too young) but we probably will.
Could be interesting on Velocity side. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki….
Regards,
Claude
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2300
days inactive
2999
days old
8 comments
4 participants
participants (4)
-
Claude Brisson -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol