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

I guess I was not clear enough. This option does indeed exist in 1.7. I just wanted to make sure it does not get dropped in 2.0 as part of the cleanup work. Alex On Mon, Jan 30, 2017 at 4:04 PM, Nathan Bubna wrote: > On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna

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

On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna wrote: > On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov wrote: > >> You guys should definitely leave a way of disabling the toString() >> conversion in boolean expressions. >> > > Seems reasonable, and also

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

On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov wrote: > You guys should definitely leave a way of disabling the toString() > conversion in boolean expressions. > Seems reasonable, and also familiar; this may have been discussed before. > There are many places where people do

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: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

Shame that i can't remember anymore all my reasons for wanting those "getAs" lookups. Wondering why getAsNumber and getAsBoolean are here too. Anyone else recall the use case? And assuming that i had good reason (that did happen sometimes ), i wonder why i pushed for bucking the "to()" convention.

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

What is the problem? Velocity "truthiness": https://issues.apache.org/jira/browse/VELOCITY-692 It should definitely be part of 2.0. I missed it because the issue was closed, we should have opened a 2.0 one to remember it. Thats's the problem if a closed/resolved issue does not have an

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Am 2017-01-27 um 00:27 schrieb Claude Brisson: On 26/01/2017 19:45, Michael Osipov wrote: Am 2017-01-26 um 18:37 schrieb Claude Brisson: Now my question is: do you or someone else think that the OSGi missing meta-informations are a show stopper for the 2.0? Otherwise, my plan is to open

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

On 26/01/2017 19:45, Michael Osipov wrote: Am 2017-01-26 um 18:37 schrieb Claude Brisson: Now my question is: do you or someone else think that the OSGi missing meta-informations are a show stopper for the 2.0? Otherwise, my plan is to open JIRA issues for all those remarks, try to release

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Am 2017-01-26 um 17:54 schrieb Claude Brisson: On 26/01/2017 14:11, Michael Osipov wrote: [...] * StringUtils#normalizePath() can likely be replaced with Common IO's FilenameUtils#normalize() If we take this route, then we'll shade the commons-io class. Absolutely, they might be other spots

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Am 2017-01-26 um 18:37 schrieb Claude Brisson: Now my question is: do you or someone else think that the OSGi missing meta-informations are a show stopper for the 2.0? Otherwise, my plan is to open JIRA issues for all those remarks, try to release the RC6, and handle the issues in 2.0.1 or

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Now my question is: do you or someone else think that the OSGi missing meta-informations are a show stopper for the 2.0? Otherwise, my plan is to open JIRA issues for all those remarks, try to release the RC6, and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one I'm not

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

On 26/01/2017 14:11, Michael Osipov wrote: [...] * StringUtils#normalizePath() can likely be replaced with Common IO's FilenameUtils#normalize() If we take this route, then we'll shade the commons-io class. * StringUtils#nullTrim() can be replaced with Commons Lang's StringUtils#trim() *

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Ahh java, now seems so many different ways of doing the same thing Just importing a file, I also have standard utils. The path is the tricky one now, without testing it. value = FileUtils.readFileToString(new File( getProject().resolveFile(value)

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Hello, I use the taxen task, and now have a local copy as its no longer supported. What would be an equivalent to .fileContentsToString(..) as its now missing? org.apache.velocity.util.StringUtils value = StringUtils.fileContentsToString(

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Am 2017-01-26 um 04:39 schrieb Claude Brisson: A new test build of Velocity Engine 2.0 is available (RC6). No determination as to the quality ('alpha,' 'beta,' or 'GA') of Velocity Engine 2.0 has been made, and at this time it is simply a "test build". We welcome any comments you may have, and

[ANNOUNCE] Velocity Engine 2.0 RC6 test build available

A new test build of Velocity Engine 2.0 is available (RC6). No determination as to the quality ('alpha,' 'beta,' or 'GA') of Velocity Engine 2.0 has been made, and at this time it is simply a "test build". We welcome any comments you may have, and will take all feedback into account if a