Re: release is ready

Maven repo does not seem to show 2.0 for the overall velocity jar: http://repo1.maven.org/maven2/org/apache/velocity/velocity/ On Sun, Aug 6, 2017 at 2:01 PM, Claude Brisson wrote: > The maven artefact has been publish, the release is visible on apache > mirrors, and the

Re: Velocity truth

I would try to something similar to Javascript convention https://javascriptweblog.wordpress.com/2011/02/07/truth-equality-and-javascript/ substituting CharSequence instead of String (so that other empty String like objects i.e. StringBuilder would evaluate as false) and also treating empty arrays

Re: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

ubna <nbu...@gmail.com> wrote: > > > On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov <a...@kayak.com> wrote: > > > >> You guys should definitely leave a way of disabling the toString() > >> conversion in boolean expressions. > >> > > > &g

Re: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

You guys should definitely leave a way of disabling the toString() conversion in boolean expressions. There are many places where people do null checks if #if($obj)...#end. Classes almost never return an empty string or null string from the toString call. Even worse some classes may use

Re: 2.0 question

buffers and file mapping to address a real performance > gain. This is not the purpose of the 2.0 version. > > Claude > > > > On 13/12/2016 16:01, Alex Fedotov wrote: > >> I guess it depends what Writer is used. >> StringBuilderWriter.append(Char

Re: 2.0 question

be taken in > upstream code that may expect to encounter String values and may otherwise > call toString(), voiding the benefice. Worth looking at, though ; it must > not be too difficult to have this code take CharSequence values into > account. > > Claude > > > >

Re: 2.0 question

that I may borrow... > > > > On 11/12/2016 17:07, Alex Fedotov wrote: > >> Great thank you. >> >> Actually I would recommend removing the StringWriter. StringWriter is >> using >> StringBuffer inside which is synchronized. >> In case of ASTStringLiteral t

Re: 2.0 question

Brisson <cla...@renegat.net> wrote: > FYI, we got rid of the Executor pattern in the events API, and we now > always provide the current Context when calling handlers. > > > On 29/11/2016 23:25, Alex Fedotov wrote: > [...] > >> We have run into some other

Re: 2.0 question

guess this would be covered by passing the Context to all event handlers. Alex On Wed, Nov 30, 2016 at 11:26 AM, Alex Fedotov <a...@kayak.com> wrote: > As far as event handlers and passing the RuntimeServices in > initialization. There is no problem with that, except that t

Re: 2.0 question

t; interfaces while deprecating the old ones. > > It's about the fourth or fifth time that I prepare a release candidate, > but I think it's worth. Hopefully I'm now pretty used to it... > > On 29/11/2016 23:25, Alex Fedotov wrote: > > [...] > > It seems like there is a some unn

Re: [VOTE] 2.0 Release Quality

One more item that we had to fix is use of exceptions to control flow. Stuff like this: Parser$LookaheadSuccess : if (jj_la == 0 && jj_scanpos == jj_lastpos) throw jj_ls; I think there was something like that in VelocityCharStream as well. When creating exceptions for normal control flow

Re: 2.0 question

another copy. I can dig up a few other things we fixed in our version if you guys are interested. Alex On Mon, Nov 28, 2016 at 11:48 PM, Claude Brisson <cla...@renegat.net> wrote: > Hi Alex. > > Thanks for your feedback. > > On 28/11/2016 20:52, Alex Fedotov wrote:

2.0 question

Hello All, ContextAware interface in Velocity is not really workable in a multi-threaded environment. The handler is a singleton and setting the Context on the singleton from multiple threads is not going to work well, short of using some form of thread local. Also the event handlers (such as

Re: Velocity 2.0 (trunk) macro synchronization

in the issue. Claude On 04/03/2015 17:48, Alex Fedotov wrote: Hello Guys, We use Velocity quite a bit and are considering moving forward and deploying the trunk build in production even though there never was a 2.0 release. We currently use a custom 1.7 build with a couple of bugs fixed by us

Re: Velocity 2.0 (trunk) macro synchronization

the normal lookup in the calling template or in the Template list (macroLibraries). Alex On Fri, Mar 6, 2015 at 11:54 AM, Nathan Bubna nbu...@gmail.com wrote: inline... On Fri, Mar 6, 2015 at 7:48 AM, Alex Fedotov a...@kayak.com wrote: One more question. One of the other areas we making

Re: Velocity 2.0 (trunk) macro synchronization

There are some open questions though: There is a very useful method Template.merge(Context, Writer, List macroLibraries). Should these macroLibraries be treated as global or local? I believe they are treated as local now. Alex On Fri, Mar 6, 2015 at 12:08 PM, Alex Fedotov a...@kayak.com wrote

Velocity 2.0 (trunk) macro synchronization

Hello Guys, We use Velocity quite a bit and are considering moving forward and deploying the trunk build in production even though there never was a 2.0 release. We currently use a custom 1.7 build with a couple of bugs fixed by us. One area where we are going to make some changes before it can