Re: Versioning

[Nathan Bubna]

Sorry for the late reply. I sadly have very limited time for Apache work
these days.

The commit log is incidental. It would ideally have no repeated versions,
but it's hardly a transgression if it does. Likewise, it's not a
requirement of the ASF that our releases never skip version numbers. It
would be nice if they did not, but again, it's not a serious issue. Put
otherwise, logs and versions are there to serve the creation of a release.
And "release" is the word we need to take seriously.  We did not release
4.2. We still could. We could also move on and release 4.2.1. As long as we
are clear that if we didn't get three +1 votes on a build, then it can't be
called a release, and thus is not a released version.


On Wed, Apr 10, 2024 at 1:04 PM Claude Brisson 
wrote:

> Hi team.
>
> Can we clarify a little bit the versioning for the future releases?
>
> My point of view is quite simple: did the engine 4.2 get released? No.
> So it should be the next version. If it's not what is intended, I need a
> detailed explanation, because I really don't understand Michael response:
>
>  > because that version should not appear more than once on the log:
> https://github.com/apache/velocity-engine/commits/master/.
>
> What do you mean exactly by the fact that a "version" does "appear" on
> the "log"? None of those terms are clear to me in this context...
>
> Regards,
>
>Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Release Velocity Engine version 2.4

[Nathan Bubna]

+1

On Sat, Feb 10, 2024 at 11:33 AM Michael Osipov  wrote:

> Hi,
>
> Release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310104=12352138
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachevelocity-1041/
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1041/org/apache/velocity/velocity-engine-parent/2.4/velocity-engine-parent-2.4-source-release.zip
>
> Source release checksum(s):
> velocity-engine-parent-2.4-source-release.zip
> sha512:
>
> 7f1237d6871774fd56e0390941843a7da2074b17f9428c2532f6546cb95a7ed6e41433e864666ed77bb689d4c6925bd61b91e6e9d6d30be1abdb89a63f28ad1a
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Release Velocity Tools version 3.2

[Nathan Bubna]

+1

On Sat, Feb 10, 2024 at 11:42 AM Michael Osipov  wrote:

> Hi,
>
> IMPORTANT: This requires the following staging repo:
> https://repository.apache.org/content/repositories/orgapachevelocity-1041/
>
> Release notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310130=12351146
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachevelocity-1042/
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1042/org/apache/velocity/tools/velocity-tools-parent/3.2/velocity-tools-parent-3.2-source-release.zip
>
> Source release checksum(s):
> velocity-tools-parent-3.2-source-release
> sha512:
>
> 6fb10aa15a43e820b3d7bf398e09ebdc2be854253d004b8962108fb4f311e4d5dd952ebfe04e22365c04334be3578c0ef12fcc18f37efd918bf0a6faaa213435
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Release Velocity Master version 6

[Nathan Bubna]

+1

On Sat, Feb 3, 2024 at 10:07 AM Michael Osipov  wrote:

> Hi,
>
> Changelog:
> * Upgrade to Apache Parent 31
> * Explicitly require Maven 3.2.5+ at build time
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachevelocity-1040/
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1040/org/apache/velocity/velocity-master/6/velocity-master-6-source-release.zip
>
> Source release checksum(s):
> velocity-master-6-source-release.zip
> sha512:
>
> d95b652d327b9efc17f8ef0959f15c71a1fcef79c2497d1ea5713a466d1e7035a9e4132ea48f2db8f692672c831ba8430c1ba1164aa5e0faeb24b8645bcc2bcf
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Release Velocity Master version 5

[Nathan Bubna]

+1

On Sat, Mar 25, 2023 at 4:59 AM Claude Brisson 
wrote:

> Hello.
>
> Please vote for the release of the velocity-master release 5.
>
> Changes:
>
> + upgraded parent apache pom to version 29
> + upgraded maven plugins to latest version
> + list Will Glass-Husain as Emeritus (I still wonder why we list the
> staff in the master pom by the way)
>
> Staging repository :
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1039/
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1039/org/apache/velocity/velocity-master/5/velocity-master-5-source-release.zip
>
>
> Source release checksum(s):
> velocity-master-5-source-release.zip
> sha512:
>
> 853d13c9cbe0dc7f597538420baa07ad27492a2a4a870e4095c93fd7d573a986ddcfd3d96923c102e3fd03b16df520e7e8471e2805c1de9aa93886994477926d
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>Claude
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Releasing Velocity Tools 3.2

[Nathan Bubna]

The javax->jakarta migration is unbelievably wasteful. So much stupid.

But yes, we probably have to make that a major version change. Which is
also very dumb. And unfortunately, i have zero time to help. :(

On Wed, Mar 22, 2023 at 3:24 AM Claude Brisson 
wrote:

> And it should be better to first push out a release of the engine (there
> is at least one CVE on the jdom dependency).
>
> Ah, and follow the movement and make the javax => jakarta migration,
> shouldn't we? Then, how? Does it imply a major version change? If yes,
> it means two releases per module...
>
>Claude
>
> PS - read somewhere on twitter: "I wish to know how many man-years the
> whole #Java developers community wasted on the idiotic javax -> jakarta
> migration so far, and more important I wish there could be a way to make
> @Oracle to pay for it."
>
>
> On 14/03/2023 11:06, Michael Osipov wrote:
> > Am 2023-03-14 um 01:15 schrieb Claude Brisson:
> >> There is some work on the open issues... I'll try to get some done.
> >
> > Merci, Claude !
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > For additional commands, e-mail: dev-h...@velocity.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Resigning from Apache Velocity PMC

[Nathan Bubna]

Agreed. Thanks for your long work here, Will. If you're ever in Portland,
drop me a line and i'll buy you a drink. :)

On Thu, Mar 11, 2021 at 12:11 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> Will, Thank you so much for your time and the part of the journey that we
> walked together. I hope we still see you around here from time to time.
>
> Looking forward to going back to in-person conferences as well, when this
> is all done, we should get together for beers again.
>
> -h
>
>
> On Wed, Mar 10, 2021 at 9:07 PM Will Glass-Husain 
> wrote:
>
> > Dear Team,
> >
> > Please accept my resignation from the Apache Velocity PMC -- my time
> > for volunteer efforts has dwindled and it's time to make it official.
> >
> > Been a pleasure being part of this community over the last 15 years
> > and look forward to bumping into some of you at conferences, online,
> > etc in the future.
> >
> > Cheers,
> > WILL
> >
> > -
> > To unsubscribe, e-mail: private-unsubscr...@velocity.apache.org
> > For additional commands, e-mail: private-h...@velocity.apache.org
> >
> >
>

Re: [ANNOUCE] Apache Velocity Engine 2.3 Released

[Nathan Bubna]

Thank you, Claude!!  I really appreciate all your work getting these
releases out!

On Mon, Mar 8, 2021 at 4:12 PM Claude Brisson  wrote:

> The Apache Velocity community is pleased to announce the release of
> Apache Velocity Engine 2.3 The release is available for download at:
>
>https://velocity.apache.org/download.cgi
>
> Apache Velocity is well-known in the Java field as a lightweight,
> easy-to-use templating library for creating dynamic web sites and
> performing other text-generation tasks. It relies on the Velocity
> Template Language (VTL) which is aimed at ease-of-use and simplicity.
>
> Main changes in this release:
>
>
> * Fix a minor security issue in user-edited templates applications: let
> SecureUberspector block methods on ClassLoader and subclasses.
>
> * New spring-velocity-support module for Velocity Engine integration in
> Spring Framework.
>
> For a full list of changes, consult the Velocity Engine 2.3 Changes
> section:
>
>https://velocity.apache.org/engine/2.3/changes.html
>
> as well as the JIRA changelog:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310104=12348601
>
> For notes on upgrading, see Velocity Engine 2.3 Upgrading section:
>
>http://velocity.apache.org/engine/2.3/upgrading.html
>
> Regards,
>
>the Apache Velocity team.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Engine 2.3 RC2 Release quality

[Nathan Bubna]

+1 GA

On Wed, Mar 3, 2021 at 4:29 AM Claude Brisson 
wrote:

> The Velocity Engine 2.3 RC2 is available since February 27.
>
> Main changes in this release:
>
> + New spring-velocity-support module, containing Spring framework
> Velocity Engine integration classes.
> + Security fix: let SecureUberspector block methods on ClassLoader and
> subclasses.
>
> Changes from RC1 to RC2:
>
> + Fixes in testcases for OpenJDK 11 and 15
> + Review alternate values implementation, with added testcases
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1038
>
> Documentation:
>
> * http://velocity.apache.org/engine/2.3/
>
> Sources:
>
>   * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1
>
> Please note than when evaluating this module, you will need to also
> install velocity-master version 4 to your local maven repository, with
> commands like:
>
> $ git clone --branch velocity-master-4
> https://github.com/apache/velocity-master.git
> $ cd velocity-master/pom
> $ mvn install
>
> If you have had a chance to review the test build, please respond with a
> vote on its quality:
>
>
>   [ ] Leave at test build
>   [ ] Alpha
>   [ ] Beta
>   [ ] General Availability (GA)
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Tools 3.1 RC1 Release quality

[Nathan Bubna]

+1 GA

On Mon, Mar 1, 2021 at 12:26 PM Claude Brisson 
wrote:

> The Velocity Tools 3.1 RC1 is available since February 27.
>
> Main changes in this release:
>
> + Added an optional 'factory' attribute to tools with the classname of a
> factory for creating new tools instances
> + Added a new BreadcrumbTool meant to help displaying UI breadcrumb trails
> + Fix potential XSS vulterability in VelocityViewServlet error handling.
>
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1037
>
> Documentation:
>
> * https://velocity.apache.org/tools/3.1
>
> Sources:
>
> * https://github.com/apache/velocity-tools/releases/tag/3.1-RC1
>
> Please note than when evaluating this module, you will need to also
> install velocity-master version 4 AND velocity-engine version 2.3 to
> your local maven repository, with commands like:
>
> $ git clone --branch velocity-master-4
> https://github.com/apache/velocity-master.git
> $ cd velocity-master
> $ mvn install
> $ cd ..
> $ git clone --branch 2.3-RC1 https://github.com/apache/velocity-engine.git
> $ cd velocity-engine
> $ mvn install
>
> If you have had a chance to review the test build, please respond with a
> vote on its quality:
>
>
>   [ ] Leave at test build
>   [ ] Alpha
>   [ ] Beta
>   [ ] General Availability (GA)
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Engine 2.3 RC1 Release quality

[Nathan Bubna]

+1 GA

On Mon, Mar 1, 2021 at 8:06 AM Claude Brisson 
wrote:

> The Velocity Engine 2.3 RC1 is available since February 27.
>
> Main changes in this release:
>
> + New spring-velocity-support module, containing Spring framework
> Velocity Engine integration classes.
> + Security fix: let SecureUberspector block methods on ClassLoader and
> subclasses.
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1036
>
> Documentation:
>
> * http://velocity.apache.org/engine/2.3/
>
> Sources:
>
>   * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1
>
> Please note than when evaluating this module, you will need to also
> install velocity-master version 4 to your local maven repository, with
> commands like:
>
> $ git clone --branch velocity-master-4
> https://github.com/apache/velocity-master.git
> $ cd velocity-master
> $ mvn install
>
> If you have had a chance to review the test build, please respond with a
> vote on its quality:
>
>
>   [ ] Leave at test build
>   [ ] Alpha
>   [ ] Beta
>   [ ] General Availability (GA)
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Fwd: [VOTE] Release Velocity Master version 4

[Nathan Bubna]

Henning errantly didn't send this to the list, forwarding it on his behalf.
:)

-- Forwarded message -
From: Henning Schmiedehausen 
Date: Sat, Feb 27, 2021 at 8:07 PM
Subject: Re: [VOTE] Release Velocity Master version 4
To: Nathan Bubna 


Ok. Thanks.

+1 to release.



On Sat, Feb 27, 2021 at 20:06 Nathan Bubna  wrote:

> Hmm. I didn't check the SHA. Not sure on that. As for the "mostly empty",
> this is the release of the Velocity Master POM. That's all that should be
> in it. Votes for Tools and Engine releases will come shortly, methinks.
>
> On Sat, Feb 27, 2021 at 4:45 PM Henning Schmiedehausen 
> wrote:
>
>> Hi Nathan,
>>
>> I have been out of the loop for quite some time, but the repos seem to be
>> mostly empty to me and they do not match the sha:
>>
>> sha512sum ~/Downloads/velocity-master-4-source-release.zip
>> 8b7566ebf696e529de8d79a1443418a818be3169b71682f434fdcb30367ab858cc42922b456bd9e87846fdf9aee6fad7e2e6de79d6fbf3091c0beded65a69b09
>>  /Users/henning/Downloads/velocity-master-4-source-release.zip
>>
>>  unzip -l ~/Downloads/velocity-master-4-source-release.zip
>> Archive:  /Users/henning/Downloads/velocity-master-4-source-release.zip
>>   Length  DateTimeName
>> -  -- -   
>> 0  01-22-2020 15:10   velocity-master-4/
>>  7769  01-22-2020 15:10   velocity-master-4/pom.xml
>>   271  01-22-2020 15:10   velocity-master-4/DEPENDENCIES
>> 11358  01-22-2020 15:10   velocity-master-4/LICENSE
>>   178  01-22-2020 15:10   velocity-master-4/NOTICE
>> - ---
>> 19576 5 files
>>
>> Am I doing this right?
>>
>> -h
>>
>>
>>
>>
>>
>>
>> On Sat, Feb 27, 2021 at 7:57 AM Nathan Bubna  wrote:
>>
>>> Hey gents,
>>>
>>> The board is breathing down our necks because there's a public (but
>>> minor) security issue. Claude's put a bunch of work in to make this happen.
>>> Please jump in with some quick checks and votes (or even trust and vote, if
>>> need be), so we can get the master pom, engine, and tools releases out
>>> promptly.
>>>
>>> Thanks,
>>> Your friendly neighborhood PMC chair.
>>>
>>> -- Forwarded message -
>>> From: Claude Brisson 
>>> Date: Sat, Feb 27, 2021 at 2:15 AM
>>> Subject: [VOTE] Release Velocity Master version 4
>>> To: Velocity Developers List 
>>>
>>>
>>> Hi.
>>>
>>> Here's an RC for velocity-master-4, with the following changes:
>>>
>>> + set maven-enforcer-plugin and extra-enforcer-rules plugins versions
>>> + removed Antonio as emeritus, as per his request
>>> + switched scm URLs from svn to git
>>> + added README.md file
>>> + updated apache parent to 23
>>>
>>> Staging repo:
>>>
>>> https://repository.apache.org/content/repositories/orgapachevelocity-1035/
>>>
>>> https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip
>>>
>>> Source release checksum(s):
>>> velocity-master-4-source-release.zip
>>> sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>>
>>>

Re: [VOTE] Release Velocity Master version 4

[Nathan Bubna]

+1

On Sat, Feb 27, 2021 at 2:15 AM Claude Brisson 
wrote:

> Hi.
>
> Here's an RC for velocity-master-4, with the following changes:
>
> + set maven-enforcer-plugin and extra-enforcer-rules plugins versions
> + removed Antonio as emeritus, as per his request
> + switched scm URLs from svn to git
> + added README.md file
> + updated apache parent to 23
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachevelocity-1035/
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip
>
> Source release checksum(s):
> velocity-master-4-source-release.zip
> sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [ANNOUCE] Velocity Engine 2.3 test build available

[Nathan Bubna]

Thank you, Claude! I really appreciate you getting this out.

On Sat, Feb 27, 2021 at 5:14 AM Claude Brisson 
wrote:

> The test build of Velocity Engine 2.3 RC1 is available.
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> Velocity Engine 2.3 RC1 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 quality vote is called for this build.
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html
>
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1036
>
> Documentation:
>
> * http://velocity.apache.org/engine/2.3/
>
> Sources:
>
>   * https://gitbox.apache.org/repos/asf?p=velocity-engine.git
>   * https://github.com/apache/velocity-engine
>
> A vote regarding the quality of this test build will be initiated soon.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Broken: apache/velocity-engine#21 (master - 1a22c95)

[Nathan Bubna]

Agreed. Travis will get over it. :)

On Sat, Feb 27, 2021 at 3:15 AM Claude Brisson 
wrote:

> Of course, anticipating upon yet unreleased artifacts breaks CI. But if
> we are to release master, engine and the tools in a raw ASAP to please
> the security team, we should launch parallel release processes and let
> Travis cry.
>
> It just means that one must install parent artifacts when validating a
> dependent one.
>
>
>  Forwarded Message 
> Subject:Broken: apache/velocity-engine#21 (master - 1a22c95)
> Date:   Sat, 27 Feb 2021 11:01:22 +
> From:   Travis CI 
> To: cla...@renegat.net
>
>
>
> apache
>
> /
>
> velocity-engine
>
> <
> https://travis-ci.com/github/apache/velocity-engine?utm_medium=notification_source=email>
>
>
>
> branch iconmaster 
>
> build has failed
> Build #21 was broken
> <
> https://travis-ci.com/github/apache/velocity-engine/builds/218432260?utm_medium=notification_source=email
> >
> arrow to build time
> clock icon1 min and 15 secs
>
> Claude Brisson avatarClaude Brisson
>
> 1a22c95 CHANGESET →
> <
> https://github.com/apache/velocity-engine/compare/aade2612b1f9...1a22c9542718>
>
>
>
> [engine] Anticipate master version increment
>
> Want to know about upcoming build environment updates?
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
>
> SIGN UP HERE 
>
> book icon
>
> Documentation  about Travis CI
>
> Have any questions? We're here to help. 
> Unsubscribe
> <
> https://travis-ci.com/account/preferences/unsubscribe?repository=16807037_medium=notification_source=email>
>
> from build emails from the apache/velocity-engine repository.
> To unsubscribe from *all* build emails, please update your settings
> <
> https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email>.
>
>
> black and white travis ci logo 
>
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: cont...@travis-ci.com  |
> Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß
> §27 a Umsatzsteuergesetz: DE282002648
>
>

Re: Default github branches

[Nathan Bubna]

On Mon, Feb 22, 2021 at 12:13 AM Claude Brisson 
wrote:

>  From what I understood, it's github which is asking for the change, not
> enforcing it.
>
> For the record, I am supposed to come back to infra with a link to a
> mail thread -aka this one- to act our decision. So +1s needed.
>
> Since there is a bit of a workload currently with the engine release to
> push out, I update my proposal: let just switch only velocity-site for
> now towards main, we'll update the others later on.
>


+1 Makes sense. Thanks, Claude!


> On 21-02-01 11 h 37, Michael Osipov wrote:
> > Am 2021-01-29 um 19:29 schrieb Claude Brisson:
> >> Hi folks.
> >>
> >> I recently opened a routine ticket to infra to have the default
> >> github branch of apache/velocity-site moved from trunk to master (a
> >> change which is already effective in our other projects) :
> >> https://issues.apache.org/jira/browse/INFRA-21355
> >>
> >> But I was asked in return to discuss this change within our
> >> community, as it appears that since October, github is using "main"
> >> as the default branch for new repositories, and promoting the change
> >> from "master" to "main" for existing ones.
> >>
> >> The reason behind this is "part of the company's effort to remove
> >> unnecessary references to slavery and replace them with more
> >> inclusive terms."
> >>
> >> I have no problem on my side with this change, but it should be more
> >> consistent to do it in all our repositories.
> >>
> >> So, any objection to switch the default branch from "master" to
> >> "main" on all our repositories?
> >
> > I don't mind to switch. I wonder whether there is a general foundation
> > stance on this or every TLP decides for itself.
> >
> > M
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > For additional commands, e-mail: dev-h...@velocity.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Limiting VelocityLayoutServlet buffer size

[Nathan Bubna]

On Fri, Dec 18, 2020 at 3:01 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Nathan,
>
> On 12/16/20 12:43, Nathan Bubna wrote:
> > In general, i think the overhead from StringWriter is probably pretty
> minimal.
> >
> > Before worrying about it, I'd want to see some profiling that showed  it
> was a problem.
>
...

> In Java 8, StringBuilder wins by a factor of 10. In Java 15, it's a
> factor of ~20.
>
...

That's impressive.



> The question is whether or not it will make a difference when using a
> StringWriter
> versus a proposed StringBuilderWriter when the thing that's likely to
> take the most time is the many re-sizes of the internal char[] array
> that both use.
>

Yup. Impressive gains in a focused area don't give the full picture.

...

> Perhaps starting with a larger-than-default buffer for those will also
> help. (The default size of a StringWriter -- which is what
> VelocityLayoutServlet uses - is a mere 16 characters). I find it
> unlikely that such a small buffer would be practical for most Velocity
> workloads. Maybe we can improve performance a bit by specifying a larger
> default buffer/builder size to avoid some of the initial buffer-resizes
> that will inevitably occur.
>

Heh. I didn't realize StringWriter was so small by default. Sounds like a
promising optimization. 16 chars is obviously ludicrously small for
templating.

> Our dev resources these days are limited and things are pretty
> > stable, so i'm wary of taking on optimizations that increase our
> > complexity.
>

Honestly, the changes you are talking about are not that complex. I'm just
overwhelmed. This seems overcautious of me to bother saying in hindsight.
But you can probably see by how long i've let Velocity emails languish that
i just don't have useful amounts of time for it myself.

[jira] [Commented] (VELOCITY-933) Spring support for Velocity

[Nathan Bubna (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284007#comment-17284007
 ] 

Nathan Bubna commented on VELOCITY-933:
---

I didn't actually try that. And actually, i can't figure out a way to edit it, 
despite the fact that it claims to be fully unlocked.

> Spring support for Velocity
> ---
>
> Key: VELOCITY-933
> URL: https://issues.apache.org/jira/browse/VELOCITY-933
> Project: Velocity
>  Issue Type: Task
>  Components: Engine
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.3
>
> Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search 
> Results.png, image-2021-02-12-12-13-04-901.png
>
>
> Add a new jar submodule for Velocity Spring support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Comment Edited] (VELOCITY-933) Spring support for Velocity

[Nathan Bubna (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283956#comment-17283956
 ] 

Nathan Bubna edited comment on VELOCITY-933 at 2/12/21, 8:13 PM:
-

Not sure i have any perms to edit wiki restrictions, nor whether you need 
special permission:
 !image-2021-02-12-12-13-04-901.png|width=601,height=197!


was (Author: nbubna):
Not sure i have any perms to edit wiki restrictions, nor whether you need 
special permission:
!image-2021-02-12-12-13-04-901.png!

> Spring support for Velocity
> ---
>
> Key: VELOCITY-933
> URL: https://issues.apache.org/jira/browse/VELOCITY-933
> Project: Velocity
>  Issue Type: Task
>  Components: Engine
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.3
>
> Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search 
> Results.png, image-2021-02-12-12-13-04-901.png
>
>
> Add a new jar submodule for Velocity Spring support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELOCITY-933) Spring support for Velocity

[Nathan Bubna (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283956#comment-17283956
 ] 

Nathan Bubna commented on VELOCITY-933:
---

Not sure i have any perms to edit wiki restrictions, nor whether you need 
special permission:
!image-2021-02-12-12-13-04-901.png!

> Spring support for Velocity
> ---
>
> Key: VELOCITY-933
> URL: https://issues.apache.org/jira/browse/VELOCITY-933
> Project: Velocity
>  Issue Type: Task
>  Components: Engine
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.3
>
> Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search 
> Results.png, image-2021-02-12-12-13-04-901.png
>
>
> Add a new jar submodule for Velocity Spring support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Updated] (VELOCITY-933) Spring support for Velocity

[Nathan Bubna (Jira)]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nathan Bubna updated VELOCITY-933:
--
Attachment: image-2021-02-12-12-13-04-901.png

> Spring support for Velocity
> ---
>
> Key: VELOCITY-933
> URL: https://issues.apache.org/jira/browse/VELOCITY-933
> Project: Velocity
>  Issue Type: Task
>  Components: Engine
>Affects Versions: 2.3
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.3
>
> Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search 
> Results.png, image-2021-02-12-12-13-04-901.png
>
>
> Add a new jar submodule for Velocity Spring support



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Limiting VelocityLayoutServlet buffer size

[Nathan Bubna]

I don't honestly know much about JDK licensing, so i'll leave that to you
or others. In general, i think the overhead from StringWriter is probably
pretty minimal. Before worrying about it, i'd want to see some profiling
that showed it was a problem. Our dev resources these days are limited and
things are pretty stable, so i'm wary of taking on optimizations that
increase our complexity.


On Mon, Dec 14, 2020 at 8:38 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Nathan,
>
> On 12/14/20 11:15, Nathan Bubna wrote:
> > I'm pretty sure we don't have a setting like that.
>
> Yep, I just got into the code and was writing a patch for it:
>
> L265
>  protected void mergeTemplate(Template template, Context context,
>   HttpServletResponse response)
>  throws IOException
>  {
>  //
>  // this section is based on Tim Colson's "two pass render"
>  //
>  // Render the screen content
>  StringWriter sw = new StringWriter();
>  template.merge(context, sw);
>  // Add the resulting content to the context
>  context.put(KEY_SCREEN_CONTENT, sw.toString());
>
>
> I have a LimitedStringWriter class that can be swapped-in for
> StringWriter, but I'm having trouble building the JAR files due to an
> unrelated build issue. I'll post about that separately.
>
> If I'm going to implement a limited StringWriter class, I'm wondering if
> we shouldn't also take the opportunity to improve performance by using a
> StringBuilder internally instead of a StringBuffer (which is what
> java.io.StringWriter uses internally). Since this isn't expected to be
> multi-threaded, the overhead of synchronization on StringWriter's
> StringBuffer can be avoided. That would essentially require writing a
> complete clone of StringWriter, which, while not complicated, might
> possibly violate JDK licensing since I have recently read the code for
> StringWriter in order to build the subclass. :(
>
> I didn't see anything in commons-lang or similar existing dependencies
> that might fit the billing, so I have left it alone for now.
>
> -chris
>
> > On Mon, Dec 14, 2020 at 8:01 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> All,
> >>
> >> We recently suffered an OOME in production because we had a huge SQL
> >> query return a log of data which, in turn, generated even more HTML
> >> output for a particular screen.
> >>
> >> We got an OOME with ASTNode.render trying to call StringWriter.write
> >> (which calls StringBuffer's auto-re-sizing) because the output string
> >> simply grew too much.
> >>
> >> We are of course fixing the SQL query to make sure we limit the amount
> >> of data that can come back, but we'd also like to make sure that
> >> Velocity doesn't trigger an OOME like this if possible.
> >>
> >> Is there a setting for limiting the output buffer size? I haven't yet
> >> found one in the documentation, so I'm starting to look in the code.
> >>
> >> Thanks,
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> >> For additional commands, e-mail: dev-h...@velocity.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Limiting VelocityLayoutServlet buffer size

[Nathan Bubna]

I'm pretty sure we don't have a setting like that.

On Mon, Dec 14, 2020 at 8:01 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> We recently suffered an OOME in production because we had a huge SQL
> query return a log of data which, in turn, generated even more HTML
> output for a particular screen.
>
> We got an OOME with ASTNode.render trying to call StringWriter.write
> (which calls StringBuffer's auto-re-sizing) because the output string
> simply grew too much.
>
> We are of course fixing the SQL query to make sure we limit the amount
> of data that can come back, but we'd also like to make sure that
> Velocity doesn't trigger an OOME like this if possible.
>
> Is there a setting for limiting the output buffer size? I haven't yet
> found one in the documentation, so I'm starting to look in the code.
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter

[Nathan Bubna (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037238#comment-17037238
 ] 

Nathan Bubna commented on VELTOOLS-184:
---

LOL. Sorry, didn't read carefully. I get it now, a single quote in a double 
quoted string is being escaped when it shouldn't be. Got it.

Yeah, a JSON-escaping method would be good. You interested in contributing a 
patch?

> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
>  Issue Type: Improvement
>  Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
>  Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant 
> with the JSON syntax. For instance, when the input string contains an 
> apostrophe ', a backslash is inserted before it because there is no way for 
> the method to know if the string is enclosed with single or double quotes. 
> This is not compliant with the JSON syntax, and some JSON parsers will reject 
> the string.
> There may be other differences between javascript and JSON strings, but this 
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second 
> javascript method with a second parameter indicating the type of quote used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter

[Nathan Bubna (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037112#comment-17037112
 ] 

Nathan Bubna commented on VELTOOLS-184:
---

[https://www.json.org/json-en.html]

Only double quoted strings are allowed in JSON.

> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
>  Issue Type: Improvement
>  Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
>  Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant 
> with the JSON syntax. For instance, when the input string contains an 
> apostrophe ', a backslash is inserted before it because there is no way for 
> the method to know if the string is enclosed with single or double quotes. 
> This is not compliant with the JSON syntax, and some JSON parsers will reject 
> the string.
> There may be other differences between javascript and JSON strings, but this 
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second 
> javascript method with a second parameter indicating the type of quote used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Problems with commons-beanutils-1.9.4

[Nathan Bubna]

Or maybe even just put a 3.x compatible version of the Struts tools up on
github as an independent fork. Probably easier than talking the Struts devs
into it.

On Thu, Feb 6, 2020 at 11:10 PM Claude Brisson 
wrote:

> On 20-02-06 16 h 15, Christopher Schultz wrote:
>
> > 3.0 completely dropped support for Struts, which is a requirement for
> > me, so I don't have any current stake in velocity-tools 3.0. I'm happy
> > to do the work (delete 4 lines of code; document; commit) but I won't
> > have anything to test it with other than the existing unit tests.
>
> Does it also mean that you are stuck with Velocity 1.7? I'm pretty sure
> that the struts tools could be easily upgraded to work with tools 3.x,
> but they should probably be hosted by the struts project...
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Problems with commons-beanutils-1.9.4

[Nathan Bubna]

Yeah, moving to jetty-maven-plugin would be good. I use that heavily at
work.

As for setClass(Class cls), couldn't we just change it to:

public void setClass(String classname) {
setClassname(classname);
}

Seems like that would keep the class="org.com.Foo" config syntax working
and avoid the security issue, right?

On Thu, Feb 6, 2020 at 10:52 PM Claude Brisson 
wrote:

> Hi.
>
> I suspect the class= problem only happens when running under a security
> manager. I had set up the cargo maven plugin to run the showcase example
> under a security manager, but it was failing under window so for now
> it's commented in the showcase pom file.
>
> There are several other problems with the cargo plugin:
>   - version 1.6.x tries to download jetty using http rather than https,
> which now fails since maven2 repository now requires https
>   - version 1.7.x fixes the problem but gives a "Could not find or load
> main class" error when trying to launch jetty, I didn't investigate why
>   - jetty is never cached (other than in /tmp) and downloaded each time
> (why on earth isn't cargo using the maven repository?!)
>
> and IMO the roadmap is to just drop cargo: anyone wanting to test the
> showcase webapp using another container can just do it with the .war
> file, we can switch to directly using the jetty-maven-plugin, without
> the added complexity of a generic J2EE container manager.
>
> I wonder if just dropping the method is enough: anyone with an old
> format configuration will have trouble identifying the cause of the
> problem. Isn't there any way to tweak beanutils into binding class= to
> setClassname() ?
>
>
>Claude
>
> On 20-02-05 19 h 09, Nathan Bubna wrote:
> > Thanks for drilling into that, Chris! I was reading, but have no time to
> > help with such things right now. I imagine the beanutils folks made that
> > change as a security fix. Probably time for us to deprecate/kill the
> > setClass option, if it's unreliable. Any chance you're up for that?
> >
> > On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> All,
> >>
> >> This may be an uncommon configuration, but I just upgraded from
> >> velocity-tools-2.0 with commons-beanutils-1.9.3 to
> >> commons-beanutils-1.9.4 and all my stuff broke.
> >>
> >> I spent a few hours tracking it down and I happened to have my toolbox
> >> configured like this:
> >>
> >> 
> >>
> >>  
> >>  [...]
> >>
> >> 
> >>
> >> I was getting a message on webapp start that looked like this:
> >>
> >> FactoryConfiguration from 4 sources  with 2 toolboxes:
> >>   Toolbox 'application' with 1 properties [scope -auto-> application; ]
> >> and 12 tools:
> >>Tool 'null' => null
> >>
> >> and some other weird things like:
> >>
> >>Tool 'dateFormat' => null with 1 properties [key -auto-> dateFormat;
> ]
> >>
> >> The problem is that I was using the "class" attribute in my XML config
> >> instead of "classname".
> >>
> >> velocity-tools uses commons-digester, which uses commons-beanutils to:
> >>
> >> 1. Create an instance of ToolConfiguration for each 
> >> 2. Set the properties on ToolConfiguration for each 
> >>
> >> Then velocity-tools tries to instantiate the class you specify, put it
> >> into the toolbox, etc. The problem is with step #2 above.
> >>
> >> ToolConfiguration has two relevant setters, here:
> >>
> >> public void setClass(Class);
> >> public void setClassname(String);
> >>
> >> Before commons-beanutils-1.9.4, setting the "class" attribute in the
> >> XML would:
> >>
> >> 1. Find the "class" property on ToolConfiguration
> >> 2. Use Class.forName() to get an instance of java.lang.Class
> >> representing whatever class you wanted to use
> >> 3. Call ToolConfiguration.setClass(Class) with that instance of
> >> java.lang.Class.
> >>
> >> With commons-beanutils-1.9.4, that process fails at one point or
> >> another because commons-beanutils is no longer willing to instantiate
> >> objects of type java.lang.Class (or no longer willing to assign
> >> properties of java.lang.Class, it doesn't really matter).
> >>
> >> But because ToolConfiguration is designed to

Re: Problems with commons-beanutils-1.9.4

[Nathan Bubna]

I should have noticed i was responding on the user thread. Sorry. Taking
this just to dev, since users probably won't need to hear my response.

If you're willing to commit the change for 3.0, even though you don't use
it, that'd be great. I think you are right that just yanking the code and
documenting it in the changelog makes sense.  And yeah, this alone is
probably not worth a 2.0.1 release, so i guess leave it be.

Thanks, Chris!

On Thu, Feb 6, 2020 at 7:15 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Nathan,
>
> (Apologies for the cross-post, but this is a very dev-y response.
> After this message in the thread, I will reply only on the dev@ list).
>
> On 2/5/20 1:09 PM, Nathan Bubna wrote:
> > Thanks for drilling into that, Chris! I was reading, but have no
> > time to help with such things right now. I imagine the beanutils
> > folks made that change as a security fix. Probably time for us to
> > deprecate/kill the setClass option, if it's unreliable. Any chance
> > you're up for that?
>
> Sure. It's easy to do; just drop the method completely.
>
> I might argue for a transitional period where we change setClass() to
> either issue a WARN log message or even throw an exception, but anyone
> upgrading to commons-beanutils-1.9.4 or later will find that it stops
> working and that method never ever gets called, so it's kind of wasted
> effort.
>
> Anyone upgrading velocity-tools will likely be upgrading
> commons-beanutils as well (and vice-versa), so the only people who
> need the nudge to change their configurations are those who aren't
> likely to upgrade. Again, wasted effort.
>
> So I think just removing the setClass(Class) method is the proper
> course of action.
>
> I suspect there is no reason for a 2.0.1 release, so this would be a
> change only in 3.0?
>
> 3.0 completely dropped support for Struts, which is a requirement for
> me, so I don't have any current stake in velocity-tools 3.0. I'm happy
> to do the work (delete 4 lines of code; document; commit) but I won't
> have anything to test it with other than the existing unit tests.
>
> - -chris
>
> > On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > All,
> >
> > This may be an uncommon configuration, but I just upgraded from
> > velocity-tools-2.0 with commons-beanutils-1.9.3 to
> > commons-beanutils-1.9.4 and all my stuff broke.
> >
> > I spent a few hours tracking it down and I happened to have my
> > toolbox configured like this:
> >
> >    > class="org.apache.velocity.tools.generic.AlternatorTool" /> [...]
> >  
> >
> > I was getting a message on webapp start that looked like this:
> >
> > FactoryConfiguration from 4 sources  with 2 toolboxes: Toolbox
> > 'application' with 1 properties [scope -auto-> application; ] and
> > 12 tools: Tool 'null' => null
> >
> > and some other weird things like:
> >
> > Tool 'dateFormat' => null with 1 properties [key -auto->
> > dateFormat; ]
> >
> > The problem is that I was using the "class" attribute in my XML
> > config instead of "classname".
> >
> > velocity-tools uses commons-digester, which uses commons-beanutils
> > to:
> >
> > 1. Create an instance of ToolConfiguration for each  2. Set
> > the properties on ToolConfiguration for each 
> >
> > Then velocity-tools tries to instantiate the class you specify, put
> > it into the toolbox, etc. The problem is with step #2 above.
> >
> > ToolConfiguration has two relevant setters, here:
> >
> > public void setClass(Class); public void setClassname(String);
> >
> > Before commons-beanutils-1.9.4, setting the "class" attribute in
> > the XML would:
> >
> > 1. Find the "class" property on ToolConfiguration 2. Use
> > Class.forName() to get an instance of java.lang.Class representing
> > whatever class you wanted to use 3. Call
> > ToolConfiguration.setClass(Class) with that instance of
> > java.lang.Class.
> >
> > With commons-beanutils-1.9.4, that process fails at one point or
> > another because commons-beanutils is no longer willing to
> > instantiate objects of type java.lang.Class (or no longer willing
> > to assign properties of java.lang.Class, it doesn't really
> > matter).
> >
> > But because ToolConfiguration is designed to accept class names and
> > do it's own object instantiation, you can side-step the "problem"
> > introduced

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

[Nathan Bubna]

+1 Looks good to me. Thanks, Claude. Hope we can get this out before the
next board report is due. :)

On Wed, Jan 29, 2020 at 5:05 PM Claude Brisson 
wrote:

> The test build of Velocity Engine 2.2 RC6 is available.
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> Velocity Engine 2.2 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 quality vote is called for this build.
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/release-notes.html
>
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1034/
>
> Documentation:
>
> * https://velocity.apache.org/engine/2.2/
>
> Sources:
>
>   * https://svn.apache.org/repos/asf/velocity/engine/tags/2.2/
>
> Release Candidates History:
>
>   * RC1 Initial RC
>
>   * RC2
>   - added BigInteger and BigDecimal implicit conversions
>   - [VELOCITY-923] fixed a parser regression for `$foo||`
>   - [VELOCITY-904] fixed two corner case bugs for the
> velocimacro.arguments.preserve_literals backward compatibility flag
>   - fixed engine and dependency versions in README and mention the
> parser customization feature in the *building* section
>   - nicified README links
>   - upgraded surfire plugin version from 2.19.1 to 2.22.1
>   - upgraded maven-jar-plugin from 3.1.1 to 3.2.2
>   - added version 1.2 for extra-enforcer-rules
>   - upgraded maven-javadoc-plugin from 3.1.0 to 3.1.1
>   - upgraded findbugs-maven-plugin from 3.0.4 to 3.0.5
>   - upgraded maven-release-plugin from *unspecified* to 3.0.0-M1
>   - added a new templatized static class
> org.apache.velocity.runtime.VelocityEngineVersion.java
>   - use the File Separator control character to mark the end of stream
> for the parser (instead of the zero-width space char)
>   - reviewed packaging of engine examples (refreshed content, plus made
> them as a standalone zip file with readme, shell scripts, dependencies
> and examples sources rather than a meaningless standalone pom next to a
> jar without explanations...)
>
> * RC3
>   - [VELOCITY-904] fixed yet another corner case bugs for the
> velocimacro.arguments.preserve_literals backward compatibility flag
>   - upgraded SLF4J from 1.7.28 to 1.7.30
>
> * RC4
>   - [VELOCITY-904] fixed a regression introduced in RC3
>
> * RC5
>   - [VELOCITY-924] fixed cache collision between an object and its class
>   - Javadoc fixes in parser genereted classes
>   - [VELOCITY-925] fixed BC whitespace gobbling for macro call without
> parentheses
>   - [VELOCITY-926] fixed regression: Macro arguments names cannot
> collide with external references names
>   - upgraded junit from 4.12 to 4.13
>
> * RC6
> - [VELOCITY-926] fixed side effects by deprecating
> velocimacro.arguments.preserve_literals config flag in favor of
> velocimacro.enable_bc_mode, which (besides preserving arguments
> literals) uses global context values as defaults for missing macro
> arguments without explicit defaults (as did 1.7)
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [ANNOUNCE] Velocity Engine 2.2 RC4 test build available

[Nathan Bubna]

Oh yeah, i understand that from your side totally! Paying of tech debt for
big upgrades takes a long time, and i'm super grateful for your
thoroughness this time around. I'm just saying from the Velocity dev side,
it seems odd to re-add a large, complicated feature (the explicit macro
scopes are much cleaner inside and out, IMO) after two versions without it,
purely for a backward compatibility that was deprecated in a release 9+
years ago and hasn't been in a "latest and greatest" release for 3 years
now.  It's hard to justify the effort on our end. And a bit moot, since i
haven't the time for it anyway. But again, if you or Claude or someone else
wants to take it on yourselves, i won't veto at all. My favorite Apache Way
maxim has always been that those who do the work should make the decisions!

On Thu, Jan 16, 2020 at 5:12 AM Thomas Mortagne 
wrote:

> On Wed, Jan 15, 2020 at 5:31 PM Nathan Bubna  wrote:
> >
> > I don't have any time for dev work on Velocity these days, so it doesn't
> > much matter whether i consider it or not. :) If someone wants to put in
> the
> > work, i won't protest.
>
> > My inclination, ineffectual though it may be, is to
> > point out that it was removed 2 versions ago, in 2.0. Adding it back in
> as
> > a BC option in 2.2 seems more than a little belated... :)
>
> I understand but I started working on Velocity 2.x upgrade in XWiki
> quite a while ago and it took two versions because it was not very
> straightforward with XWiki using quite a lot of the Velocity APIs and
> many of those having changed a lot (some of which I'm very happy with
> but was still some work) and then start testing actual use cases to
> find out regressions or planned but not obvious breaking changes in
> actual language from XWiki extensions point of view. My bad judgment
> was to wait for 2.1 before testing more use cases because there was a
> lot of retro compatible flags and bug fixes in it that I needed while
> I should have tested right away with 2.1 SNAPSHOTS like I do now with
> 2.2 but it was also not so easy to spot everything at once when those
> were hidden by now fixed regressions or new retro compatibility flags.
>
> >
> > I do agree, the 1.7-2.0 upgrade docs probably should have said that those
> > deprecated features were actually removed. That was an oversight on our
> > part.
> >
> > On Wed, Jan 15, 2020 at 1:04 AM Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > OK should probably be documented in the 1.7->2.0 upgrade then because
> > > it was not very obvious before that it was deprecated since it was the
> > > default behavior not something you could disable.
> > >
> > > So next question I guess is would you consider having it disabled by
> > > default and be able to enable with a configuration like it was done
> > > for other things in 2.1/2.2 ? I have to try :)
> > >
> > > On Tue, Jan 14, 2020 at 7:24 PM Nathan Bubna  wrote:
> > > >
> > > > This is a planned change. Implicit local scope was deprecated in 1.7
> for
> > > > removal in 2.0 and was replaced with explicit scope control objects.
> > > >
> > >
> https://velocity.apache.org/engine/devel/upgrading.html#upgrading-from-velocity-16x-to-velocity-17x
> > > >
> > > > On Tue, Jan 14, 2020 at 9:29 AM Thomas Mortagne <
> > > thomas.morta...@xwiki.com>
> > > > wrote:
> > > >
> > > > > Took me a while to understand it but I actually found a new
> difference
> > > > > in the way Velocity deal with variables set inside a macro.
> > > > >
> > > > > In 1.7 by default (i.e. without "velocimacro.context.localscope")
> > > > > variables set in a macro end up in both the global context and a
> local
> > > > > one and when accessing this variable later in the macro the local
> > > > > value is used retrieved (all this happen in ProxyVMContext).
> > > > >
> > > > > This means that if the macro also calls some method that update the
> > > > > global VelocityContext it won't have any effect on the following
> macro
> > > > > code because that change will be hidden by the local context.
> While I
> > > > > did not debugged on Velocity 2.2-SNAPSHOT , the result I get
> suggest
> > > > > that there is no local context in macros anymore or at least it's
> not
> > > > > used the same way in this use case.
> > > > >
> > > > > The use case in which I noticed this behavior chan

Re: [ANNOUNCE] Velocity Engine 2.2 RC4 test build available

[Nathan Bubna]

I don't have any time for dev work on Velocity these days, so it doesn't
much matter whether i consider it or not. :) If someone wants to put in the
work, i won't protest. My inclination, ineffectual though it may be, is to
point out that it was removed 2 versions ago, in 2.0. Adding it back in as
a BC option in 2.2 seems more than a little belated... :)

I do agree, the 1.7-2.0 upgrade docs probably should have said that those
deprecated features were actually removed. That was an oversight on our
part.

On Wed, Jan 15, 2020 at 1:04 AM Thomas Mortagne 
wrote:

> OK should probably be documented in the 1.7->2.0 upgrade then because
> it was not very obvious before that it was deprecated since it was the
> default behavior not something you could disable.
>
> So next question I guess is would you consider having it disabled by
> default and be able to enable with a configuration like it was done
> for other things in 2.1/2.2 ? I have to try :)
>
> On Tue, Jan 14, 2020 at 7:24 PM Nathan Bubna  wrote:
> >
> > This is a planned change. Implicit local scope was deprecated in 1.7 for
> > removal in 2.0 and was replaced with explicit scope control objects.
> >
> https://velocity.apache.org/engine/devel/upgrading.html#upgrading-from-velocity-16x-to-velocity-17x
> >
> > On Tue, Jan 14, 2020 at 9:29 AM Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > Took me a while to understand it but I actually found a new difference
> > > in the way Velocity deal with variables set inside a macro.
> > >
> > > In 1.7 by default (i.e. without "velocimacro.context.localscope")
> > > variables set in a macro end up in both the global context and a local
> > > one and when accessing this variable later in the macro the local
> > > value is used retrieved (all this happen in ProxyVMContext).
> > >
> > > This means that if the macro also calls some method that update the
> > > global VelocityContext it won't have any effect on the following macro
> > > code because that change will be hidden by the local context. While I
> > > did not debugged on Velocity 2.2-SNAPSHOT , the result I get suggest
> > > that there is no local context in macros anymore or at least it's not
> > > used the same way in this use case.
> > >
> > > The use case in which I noticed this behavior change it is a macro
> > > which initialization some variable, calls an API which execute another
> > > Velocity template (a kind of include in other words) and then use the
> > > previously set variable. What happen after upgrade is that the
> > > variable is "broken" by the other template (because the template use a
> > > variable with the same name for totally unrelated reasons).
> > >
> > > It does not affect XWiki Standard much (that's why I only found it
> > > now) and I'm not sure if it used to work only by luck or if whoever
> > > wrote that use case really was counting on macro variables to be
> > > "protected" but it might have a huge effect on some extensions.
> > >
> > > How do you feel about this change and do you want me to create a jira
> > > issue about this behavior change ?
> > >
> > > On Thu, Jan 9, 2020 at 2:50 PM Thomas Mortagne
> > >  wrote:
> > > >
> > > > False alarm actually I think, sorry for the noise.
> > > >
> > > > On Thu, Jan 9, 2020 at 2:21 PM Thomas Mortagne
> > > >  wrote:
> > > > >
> > > > > Unfortunately it seems the fix is not complete (commented on the
> Jira
> > > issue).
> > > > >
> > > > > On Tue, Jan 7, 2020 at 3:55 PM Thomas Mortagne
> > > > >  wrote:
> > > > > >
> > > > > > So that one was on me after all.
> > > > > >
> > > > > > XWiki is a big beast and I might have missed some edge case but
> let's
> > > > > > say +1 for a RC.
> > > > > >
> > > > > > On Tue, Jan 7, 2020 at 11:23 AM Thomas Mortagne
> > > > > >  wrote:
> > > > > > >
> > > > > > > There is one more thing that I want to debug today (hopefully
> > > answer
> > > > > > > before 6pm GMT+1) to check if it's a side effect of this bug,
> > > another
> > > > > > > regression or a mistake I made when I upgraded since a lot of
> APIs
> > > > > > > changed (it's not an obvious error, just a slight difference
> in the
> > > > &g

Re: [ANNOUNCE] Velocity Engine 2.2 RC4 test build available

[Nathan Bubna]

This is a planned change. Implicit local scope was deprecated in 1.7 for
removal in 2.0 and was replaced with explicit scope control objects.
https://velocity.apache.org/engine/devel/upgrading.html#upgrading-from-velocity-16x-to-velocity-17x

On Tue, Jan 14, 2020 at 9:29 AM Thomas Mortagne 
wrote:

> Took me a while to understand it but I actually found a new difference
> in the way Velocity deal with variables set inside a macro.
>
> In 1.7 by default (i.e. without "velocimacro.context.localscope")
> variables set in a macro end up in both the global context and a local
> one and when accessing this variable later in the macro the local
> value is used retrieved (all this happen in ProxyVMContext).
>
> This means that if the macro also calls some method that update the
> global VelocityContext it won't have any effect on the following macro
> code because that change will be hidden by the local context. While I
> did not debugged on Velocity 2.2-SNAPSHOT , the result I get suggest
> that there is no local context in macros anymore or at least it's not
> used the same way in this use case.
>
> The use case in which I noticed this behavior change it is a macro
> which initialization some variable, calls an API which execute another
> Velocity template (a kind of include in other words) and then use the
> previously set variable. What happen after upgrade is that the
> variable is "broken" by the other template (because the template use a
> variable with the same name for totally unrelated reasons).
>
> It does not affect XWiki Standard much (that's why I only found it
> now) and I'm not sure if it used to work only by luck or if whoever
> wrote that use case really was counting on macro variables to be
> "protected" but it might have a huge effect on some extensions.
>
> How do you feel about this change and do you want me to create a jira
> issue about this behavior change ?
>
> On Thu, Jan 9, 2020 at 2:50 PM Thomas Mortagne
>  wrote:
> >
> > False alarm actually I think, sorry for the noise.
> >
> > On Thu, Jan 9, 2020 at 2:21 PM Thomas Mortagne
> >  wrote:
> > >
> > > Unfortunately it seems the fix is not complete (commented on the Jira
> issue).
> > >
> > > On Tue, Jan 7, 2020 at 3:55 PM Thomas Mortagne
> > >  wrote:
> > > >
> > > > So that one was on me after all.
> > > >
> > > > XWiki is a big beast and I might have missed some edge case but let's
> > > > say +1 for a RC.
> > > >
> > > > On Tue, Jan 7, 2020 at 11:23 AM Thomas Mortagne
> > > >  wrote:
> > > > >
> > > > > There is one more thing that I want to debug today (hopefully
> answer
> > > > > before 6pm GMT+1) to check if it's a side effect of this bug,
> another
> > > > > regression or a mistake I made when I upgraded since a lot of APIs
> > > > > changed (it's not an obvious error, just a slight difference in the
> > > > > result but there are quite a few layers of abstractions to debug
> > > > > between the result and the Velocity engine).
> > > > >
> > > > > On Tue, Jan 7, 2020 at 10:56 AM Claude Brisson
> > > > >  wrote:
> > > > > >
> > > > > > Fixed. Thanks for the report.
> > > > > >
> > > > > > Thomas, do you think you may have any other subtle xwiki bug to
> report
> > > > > > before I push out the next RC?
> > > > > >
> > > > > > On 20-01-03 12 h 31, Thomas Mortagne wrote:
> > > > > > > Hi sorry me again,
> > > > > > >
> > > > > > > I just hit https://issues.apache.org/jira/browse/VELOCITY-924.
> > > > > > >
> > > > > > > On Wed, Jan 1, 2020 at 11:12 PM Claude Brisson
> > > > > > >  wrote:
> > > > > > >> The test build of Velocity Engine 2.2 RC4 is available.
> > > > > > >>
> > > > > > >> No determination as to the quality ('alpha,' 'beta,' or 'GA')
> of
> > > > > > >> Velocity Engine 2.1 RC3 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 quality vote is called for this
> build.
> > > > > > >>
> > > > > > >> Release notes:
> > > > > > >>
> > > > > > >> *
> > > > > > >>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/release-notes.html
> > > > > > >>
> > > > > > >> Distribution:
> > > > > > >>
> > > > > > >>*
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/
> > > > > > >>
> > > > > > >> Maven 2 staging repository:
> > > > > > >>
> > > > > > >>*
> > > > > > >>
> https://repository.apache.org/content/repositories/orgapachevelocity-1032/
> > > > > > >>
> > > > > > >> Documentation:
> > > > > > >>
> > > > > > >> * https://velocity.apache.org/engine/2.2/
> > > > > > >>
> > > > > > >> Sources:
> > > > > > >>
> > > > > > >>*
> https://svn.apache.org/repos/asf/velocity/engine/tags/2.2/
> > > > > > >>
> > > > > > >> Release Candidates History:
> > > > > > >>
> > > > > > >>* RC1 Initial RC
> > > > > > >>
> > > > > > >>* RC2
> > > > > > >>- added BigInteger and BigDecimal implicit conversions
> > > > > > >>- [VELOCITY-923] fixed a parser 

Re: Velocity + Spring MVC

[Nathan Bubna]

Yeah, adopting Spring support is unlikely to be much burden and seems well
worthwhile.

On Sat, Jun 1, 2019 at 1:48 AM Claude Brisson 
wrote:

> Hi.
>
> We are aware of the situation, and we were more or less expecting
> someone to make such a proposal. Yes, it will benefit both communities.
>
> +1 for me. I guess that if your patch includes proper test cases,
> support won't be problematic.
>
>Claude
>
> On 01/06/2019 02:32, Brent Putman wrote:
> > Hello,
> >
> > I represent the Shibboleth project (https://www.shibboleth.net/), a
> > widely-used open-source platform for federated authentication (SAML,
> > CAS, and soon OpenID Connect). We make heavy use of Velocity in our
> > codebase, as well as Spring Framework and Spring MVC.
> >
> > As you may know, in their v4.x the Spring folks decided to deprecate
> > their internal Velocity support for the Spring MVC view layer in an
> > effort to reduce their maintenance burden.  Their (new) philosophy is
> > that third-party libraries should include Spring support components in
> > their projects, rather than the other way around. In Spring 5.x they
> > completed this deprecation process by removing the Velocity view layer
> > support components from Spring MVC entirely.  More details on their
> > thinking and reasoning here:
> >
> > https://github.com/spring-projects/spring-framework/issues/18368
> >
> > My question: From the above issue comments, I see that at least one
> > person from the Velocity project was aware of this.  Does the Velocity
> > team have any current plans in the works to add Spring MVC support
> > components into the Velocity project as the Spring team advocates?  I
> > searched in the archives for this list going back awhile and didn't
> > find anything, but apologies if I missed it.
> >
> > If not, then what we wanted to propose/discuss was essentially porting
> > the latest, terminal Spring 4.x MVC Velocity components into the
> > Velocity project.  We could of course do this within our project
> > internally (and have provisionally done so, see below), but there would
> > seem to be significant value for the entire Velocity and Spring user
> > communities for this to be more widely available and officially
> > supported by the Velocity project itself.  So the main purpose of this
> > email is to gauge the level of interest in doing this (or conversely
> > objections to doing so).
> >
> > The sketch of the proposal would be to add a new Velocity Tools Maven
> > submodule (e.g. velocity-tools-view-spring), which would align with the
> > existing Tools project organization.  The scope of the code would
> > likely be very similar to what you see here in our repo, which is how
> > we are currently supporting development work on our next major version
> > based on Spring 5:
> >
> >
> http://git.shibboleth.net/view/?p=spring-extensions.git;a=tree;f=src/main/java/net/shibboleth/ext/spring/velocity
> >
> > So it's a relatively small number of classes. If the interest here is
> > positive, we would be fine with doing the initial work to produce a
> > patch (unless someone on the Velocity team would prefer to do the work
> > themselves of course).  The main issue I suppose is the Velocity
> > project taking on long-term support for these components.
> >
> > We look forward to hearing the Velocity developers' thoughts on this
> > proposal.
> >
> > Thanks,
> > Brent
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

[jira] [Commented] (VELTOOLS-180) New velocity-tools-model architecture

[Nathan Bubna (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829744#comment-16829744
 ] 

Nathan Bubna commented on VELTOOLS-180:
---

Gah, i'm stuck in jello. Sorry, been too busy with other things to stop and 
really think on this. I think the way you went is fine, of course, though i do 
think a velocity-model type project might make sense, particularly if you can 
get any community to work with you. What i wouldn't want is to bring it in 
under the Velocity PMC responsibility and have it ultimately be a one-man piece 
of an already-hurting-for-active-participants Apache project.

> New velocity-tools-model architecture
> -
>
> Key: VELTOOLS-180
> URL: https://issues.apache.org/jira/browse/VELTOOLS-180
> Project: Velocity Tools
>  Issue Type: New Feature
>  Components: Misc
>Affects Versions: 3.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
>  The new data access layer (or persistence-less ORM) module that constitutes 
> the Model Tool, and which once was the 
> [Velosurf|https://github.com/arkanovicz/velosurf] library but rewritten at 
> 90%, sits in the [model 
> branch|http://svn.apache.org/viewvc/velocity/tools/branches/model/velocity-tools-model/].
> But I started having second thoughts while coding. If you look at [this class 
> diagram|https://republicate.com/class_diagram.svg], you'll see that there are 
> only 5/6 objects that will appear in VTL contexts. The remaining of the 
> library is about 40 classes, and offers by itself an ORM which I tried to 
> keep simple and efficient also on the Java side.
> So I'm starting to think that I should just publish here the VTL related 
> objects and host the ORM library elsewhere. It's more in the spirit of 
> VelocityTools to keep things lightweight, and separate projects are the best 
> guaranty of code isolation.
> For instance, I can publish it along with other projects that I publish on 
> maven central in the com.republicate group id, like the 
> [webapp-slf4j-logger|https://github.com/arkanovicz/webapp-slf4j-logger].
> It makes velocity-tools-model rely on a project external to apache, but it's 
> not a problem per se. Or the ORM library can find its way to the apache 
> codebase through, like, a commons-model project. Or start at com.republicate 
> and then migrate. Or start here then migrate elsewhere...
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-180) New velocity-tools-model architecture

[Nathan Bubna (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823341#comment-16823341
 ] 

Nathan Bubna commented on VELTOOLS-180:
---

Do the VTL related objects have any utility without your ORM?

> New velocity-tools-model architecture
> -
>
> Key: VELTOOLS-180
> URL: https://issues.apache.org/jira/browse/VELTOOLS-180
> Project: Velocity Tools
>  Issue Type: New Feature
>  Components: Misc
>Affects Versions: 3.1
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
>  The new data access layer (or persistence-less ORM) module that constitutes 
> the Model Tool, and which once was the 
> [Velosurf|https://github.com/arkanovicz/velosurf] library but rewritten at 
> 90%, sits in the [model 
> branch|http://svn.apache.org/viewvc/velocity/tools/branches/model/velocity-tools-model/].
> But I started having second thoughts while coding. If you look at [this class 
> diagram|https://republicate.com/class_diagram.svg], you'll see that there are 
> only 5/6 objects that will appear in VTL contexts. The remaining of the 
> library is about 40 classes, and offers by itself an ORM which I tried to 
> keep simple and efficient also on the Java side.
> So I'm starting to think that I should just publish here the VTL related 
> objects and host the ORM library elsewhere. It's more in the spirit of 
> VelocityTools to keep things lightweight, and separate projects are the best 
> guaranty of code isolation.
> For instance, I can publish it along with other projects that I publish on 
> maven central in the com.republicate group id, like the 
> [webapp-slf4j-logger|https://github.com/arkanovicz/webapp-slf4j-logger].
> It makes velocity-tools-model rely on a project external to apache, but it's 
> not a problem per se. Or the ORM library can find its way to the apache 
> codebase through, like, a commons-model project. Or start at com.republicate 
> and then migrate. Or start here then migrate elsewhere...
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [VOTE] Engine 2.1 RC3 Release quality

[Nathan Bubna]

[+1] GA

On Tue, Mar 19, 2019 at 5:43 PM Claude Brisson 
wrote:

> The Velocity Engine 2.1 RC3 is available since March 15.
>
> Main changes:
>
>   * Velocity Engine 2.1 now requires JDK 1.8+
>   * Two more backward compatibility flags with 1.7: hyphens in
> identifiers and macros literal arguments handling
>   * New VTL syntax: default values for references: ${name|'John Doe'} -
> the right part can be any valid VTL expression
>   * New VTL syntax: empty loops block for #foreach directive:
> #foreach(...) ... #else ... #end
>   * Configuration keys refactoring (with backward compatibility handling)
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.1/release-notes.html
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.1/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1027
>
> Documentation:
>
> * http://velocity.apache.org/engine/2.1/
>
> Sources:
>
>   * https://svn.apache.org/repos/asf/velocity/engine/tags/2.1/
>
>
> If you have had a chance to review the test build, please respond with a
> vote on its quality:
>
>   [ ] Leave at test build
>   [ ] Alpha
>   [ ] Beta
>   [ ] General Availability (GA)
>
>--
>Claude
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [engine] StringEscapeUtils

[Nathan Bubna]

Hmm. I may not be the best to weigh in on this, as i never used event
handlers for escaping. I always preferred the direct, explicit control of
escaping via tools, and trusted myself (YMMV) not to forget escaping
anywhere important.

I'll definitely agree that we shouldn't shade. I'm perfectly comfortable
with an optional dependency, so long as it's clearly documented. And as for
providing basic escaping methods, well, if you're up for the work and like
that, go for it. Those who do the work, yada, yada. :)


On Thu, Mar 7, 2019 at 4:08 AM Claude Brisson 
wrote:

> The StringEscapeUtils class is moving from commons-lang3 to commons-text.
>
> We are using it in several reference insertion event handlers (to escape
> xml, javascript or html).
>
> For now the commons-lang3 version is still there, but deprecated. We
> should address this in engine 2.1, but how?
>
> 1) just *add* the new dependency towards commons-text
> 2) add it, but make it optional, since only people using those escaping
> event handlers will need it
> 3) move the event handlers to a new module velocity-engine-events
> containing all event handlers
> 4) use shading
> 5) switch to using an internal escaping utility
>
> First, I'd like to rule out 1), 3) and 4):
>   - adding a 192k dependency for just a few basic escaping functions
> looks overkill
>   - creating a new module just for this need is painful and awkward
>   - shading is evil, and StringEscapeUtils uses many internal classes
>
> The thing to note here is that those escaping reference insertion
> handlers are basically *examples* of reference insertion handlers,
> hardly usable in production, because how to escape a reference in a
> Javascript/HTML/XML template depends on where this reference goes (you
> don't have the same escaping needs in an attribute value and in plain
> text for instance).
>
> To properly handle escaping (beyond explicitly escaping each reference
> when needed, which is what most people do), we need to switch escaping
> context, either manually in the template (as proposed in VELOCITY-705
> [1]), or automatically by parsing the generated content on-the-fly
> (let's dream). But it's another debate.
>
> I'm usually not so fond of optional dependencies, since the main point
> of using maven is to have it handle dependencies automatically. But
> since those event handlers aren't really usable in production, I'd be ok
> with it. Or, we can just provide them basic escaping standalone methods.
>
> Thoughts?
>
>Claude
>
> [1]: https://issues.apache.org/jira/browse/VELOCITY-705
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [engine] Configuration key names refactoring proposal

[Nathan Bubna]

Seems good. No objections here. :)

On Wed, Mar 6, 2019 at 4:23 PM Claude Brisson 
wrote:

> 2.1 RC1 is history, 2.1 RC2 is on its way.
>
> Here is a proposal for the configuration keys refactoring:
>
>
> https://velocity.apache.org/engine/devel/configuration-property-changes-in-2.1.html
>
> Modify this proposal boils down to edit key name strings in
> org.apache.runtime.RuntimeConstants, the deprecation mechanism uses
> reflection to take it into account. So don't hold back your thoughts.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Merging VELOCITY-892

[Nathan Bubna]

+1 Java 8 has been around plenty long

On Fri, Feb 22, 2019 at 3:40 PM Claude Brisson 
wrote:

> Hi all.
>
> The VELOCITY-892 branch contains a fix for the corresponding issue [1].
>
> The purpose is to let the method arguments conversion handler manipulate
> the formal arguments types as java.lang.reflect.Type rather than
> java.lang.Class, so that when dealing with a method like
>
>void foo(List list)
>
> called with a string like "1,2,3", the conversion handler can choose the
> correct converter between several string->list converters.
>
> But merging the VELOCITY-892 branch back to trunk requires a minimal jdk
> version of 1.8 (because of the Type.getTypeName() method).
>
> Java SE 8 is now five years old, so I don't think it's a problem.
>
> Any objection?
>
> This would also involve raising the source and target versions to 1.8
> for consistency.
>
> [1] https://issues.apache.org/jira/projects/VELOCITY/issues/VELOCITY-892
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Velocity Tools 3.0 Release Quality

[Nathan Bubna]

On Thu, Oct 4, 2018 at 8:43 AM Claude Brisson 
wrote:

> The Velocity Tools 3.0 test build has been available since October 1st.
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.0/release-notes.html
>
> Distribution:
>
>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.0/
>
> Maven 2 staging repository:
>
>   *
> https://repository.apache.org/content/repositories/orgapachevelocity-1023
>
> Sources:
>
>   * https://svn.apache.org/repos/asf/velocity/tools/tags/3.0
>
> If you have had a chance to review the test build, please respond with a
> vote on its quality:
>
>   [ ] Leave at test build
>   [ ] Alpha
>   [ ] Beta
>   [X] General Availability (GA)
>

Looks alright in my limited testing. Thanks for your work on this gents!
Wish i had more time for Velocity, but we're not using these in current dev
and my side project time is essentially nil. :)


>
> Everyone who has tested the build is invited to vote. Votes by PMC
> members are considered binding. A vote passes if there are at least
> three binding +1s and more +1s than -1s.
>
>
>Claude
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [ANNOUNCE] Velocity Tools 3.0 test build availble (RC1)

[Nathan Bubna]

Thanks to both of you!

On Tue, Oct 2, 2018 at 12:54 PM Michael Osipov  wrote:

> Am 2018-10-01 um 22:35 schrieb Claude Brisson:
> > The test build of Velocity Tools 3.0 is available.
> >
> > No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> > Velocity Tools 3.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 quality vote is called for this build.
>
> Thank you, Claude for the hard work!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

[jira] [Commented] (VELTOOLS-143) LinkTool.uri() causes mailto: links to ignore parameters added using param() method

[Nathan Bubna (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633614#comment-16633614
 ] 

Nathan Bubna commented on VELTOOLS-143:
---

I never was happy with the complexity of this tool.

30 seconds of re-evaluation (so take this with a grain of salt), makes me think 
this could also be re-written with a "sub-tool" that gathers all the 
params/uris/etc as it goes and then only tries to sort out what things to set 
in an intelligent order when toString() (or some build() method) is finally 
called. That last part could be done using URIBuilder or URI, the main point is 
to delay construction/merging/etc until called for so that the order of the 
calls does not have to be the order of the merging/constructing/etc.

Of course, i have no time to do such things myself... :(

> LinkTool.uri() causes mailto: links to ignore parameters added using param() 
> method
> ---
>
> Key: VELTOOLS-143
> URL: https://issues.apache.org/jira/browse/VELTOOLS-143
> Project: Velocity Tools
>  Issue Type: Bug
>  Components: GenericTools
>Affects Versions: 2.0
> Environment: Velocity 1.7, Velocity Tools 2.0
>Reporter: Christopher Schultz
>Priority: Minor
>
> This worked in Velocity Tools 1.4.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [VOTE] Release Velocity Master version 3

[Nathan Bubna]

It is the parent POM for all Velocity projects. It is a released project, a
dependency for our other projects, but i would definitely not call it a
product.

On Sun, Sep 23, 2018 at 5:46 PM Will Glass-Husain 
wrote:

> Hi -- chiming in here --
>
> my apologies if I'm missing something obvious.  What exactly is this?
>  There doesn't seem to be anything here except a POM file.   Is this a
> released product or other artifact?
>
> Thanks, WILL
>
> On Sat, Sep 22, 2018 at 8:23 PM Nathan Bubna  wrote:
>
> > +1
> >
> > On Sat, Sep 22, 2018 at 3:58 PM Michael Osipov 
> > wrote:
> >
> > > Hi,
> > >
> > > * reformatted the POM to a readible state
> > > * Apache Parent upgraded to 21
> > > * added plugin management section for commonly used plugins
> > >
> > > Staging repo:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachevelocity-1021/
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachevelocity-1021/org/apache/velocity/velocity-master/3/velocity-master-3-source-release.zip
> > >
> > > Source release checksum(s):
> > > velocity-master-3-source-release.zip
> > > sha512:
> > >
> > >
> >
> 61f73c9eab4859153c87dd5637c4be09edd227bfe55537491aed2c14bc2eb800b28935acab46ac5b1319e25dd188c7ef60cfd5a33064984efd22e6b150216d18
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > > For additional commands, e-mail: dev-h...@velocity.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Velocity Master version 3

[Nathan Bubna]

+1

On Sat, Sep 22, 2018 at 3:58 PM Michael Osipov  wrote:

> Hi,
>
> * reformatted the POM to a readible state
> * Apache Parent upgraded to 21
> * added plugin management section for commonly used plugins
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachevelocity-1021/
>
> https://repository.apache.org/content/repositories/orgapachevelocity-1021/org/apache/velocity/velocity-master/3/velocity-master-3-source-release.zip
>
> Source release checksum(s):
> velocity-master-3-source-release.zip
> sha512:
>
> 61f73c9eab4859153c87dd5637c4be09edd227bfe55537491aed2c14bc2eb800b28935acab46ac5b1319e25dd188c7ef60cfd5a33064984efd22e6b150216d18
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [tools] Running under a SecurityManager

[Nathan Bubna]

Thanks, Claude! This looks great!

On Wed, Jun 20, 2018 at 5:50 PM Claude Brisson 
wrote:

> I reviewed the configuration process of the VelocityView, and it's now
> much pickier about files i/o (no more CWD accesses), plus doing sensible
> accesses via privileged actions.
>
> I activated Java Security for the showcase example (ran by the cargo
> maven plugin), and it's running with this policy file [1], Christopher,
> let me know if it does correspond to what you had in mind.
>
> [1] https://s.apache.org/fNYb
>
>Claude
>
> On 05/07/2018 10:03 PM, Christopher Schultz wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Claude,
> >
> > On 3/21/18 8:25 PM, Claude Brisson wrote:
> >> Yes, it'd be great to soon release the tools since the engine is
> >> out.
> > Apologies for not replying sooner.
> >
> >> And yes, autoconfig hasn't to be the default. Why not starting with
> >> an empty toolbox by default if it eases things for integrators. But
> >> there are two different things here: 1) *default* tools (loaded
> >> from tools.xml files inside each velocity-tools jar) 2) *standard*
> >> user toolbox configuration files
> > I know the world seems to be moving from "explicit configuration" to
> > "intelligent defaults", which is okay by me. The only problem is when
> > the explicit configuration is provided, those intelligent defaults
> > should no longer apply.
> >
> >> For 1), what about a "load-default-tools" param in the descriptor?
> >> (As usual, we would first check init-params for the concerned
> >> servlet/filter and then, if not found, the context-params). It can
> >> be false by default for 3.0, if you guys think that that's the way
> >> to go. As long as we diligently document it when releasing.
> > I think if a user wants to explicitly-load their own file,
> > explicitly-loading another "defaults" file is not a problem: either
> > just saying "yes please load defaults" or "please load this other
> > file, too, which happens to be defaults".
> >
> > JAR-loaded defaults (files) are okay with me.
> >
> >> For 2), I'm pretty sure no standard configuration file should be
> >> ever checked if an explicit configuration is provided, of course
> >> (but, by the way, why is it problematic whenever those files aren't
> >> there? Oh, I see, the SecurityManager doesn't want me to read files
> >> that do not exist, funny but perfectly logical). Would it be
> >> harmful to still check for those standard locations whenever no
> >> explicit location is given be harmful (other than itching the
> >> SecurityManager)?
> > Yes, I think that's fine. It was only surprising to see them loaded
> > when I was supplying an explicit configuration.
> >
> >> So if I understand correctly, we *also* need to use
> >> PrivilegedActions.
> > I think so. It will make the code much more SecurityManager-friendly.
> > Otherwise, I have to do ugly things like "trust my whole application"
> > instead of only the things that should be trusted.
> >
> >> Does it boils down to wrapping system calls in
> >> AccessController.doPrivileged() calls? Where and how are those
> >> calls authorized? Sorry, I never used the PrivilegedActions and
> >> SecurityManager paradigm yet. If you have some good pointers or
> >> suggestions...
> > Basically, things which require privileges should be changed from:
> >
> > String foo = System.getProperty("bar");
> >
> > to this:
> >
> > String foo;
> >
> > if(null != System.getSecurityManager()) {
> >foo = AccessController.doPrivileged(new PrivilegedAction() {
> >  @Override
> >  public String run() {
> >  return System.getProperty("bar");
> >  }
> >  });
> > } else {
> >foo = System.getProperty("bar");
> > }
> >
> > Yes, I know it's ugly and verbose but there isn't really a better way.
> >
> > BTW the SecurityManager is initialized at startup so one can easily
> > initialize a static boolean in e.g. Velocity.java or whatever and just
> > consult that rather than calling System.getSecurityManager() all the tim
> > e.
> >
> >> I don't really understand either why we're speaking of the CWD
> >> whereas all the VelocityView knows is the webapp root. But I may
> >> have missed something.
> > I'll have to look back at the balking d

Re: [tools] Running under a SecurityManager

[Nathan Bubna]

Honestly, i'm content either way, this doesn't much affect me. So, whatever
y'all think is best works for me.

On Wed, Apr 25, 2018 at 12:54 AM, Claude Brisson <cla...@renegat.net.invalid
> wrote:

> Any thoughts on this? From my side, apart from this potential point, the
> tools are ready.
>
>   Claude
>
>
>
> On 22/03/2018 01:25, Claude Brisson wrote:
>
>> Yes, it'd be great to soon release the tools since the engine is out.
>>
>> And yes, autoconfig hasn't to be the default. Why not starting with an
>> empty toolbox by default if it eases things for integrators. But there are
>> two different things here:
>> 1) *default* tools (loaded from tools.xml files inside each
>> velocity-tools jar)
>> 2) *standard* user toolbox configuration files
>>
>> For 1), what about a "load-default-tools" param in the descriptor? (As
>> usual, we would first check init-params for the concerned servlet/filter
>> and then, if not found, the context-params). It can be false by default for
>> 3.0, if you guys think that that's the way to go. As long as we diligently
>> document it when releasing.
>>
>> For 2), I'm pretty sure no standard configuration file should be ever
>> checked if an explicit configuration is provided, of course (but, by the
>> way, why is it problematic whenever those files aren't there? Oh, I see,
>> the SecurityManager doesn't want me to read files that do not exist, funny
>> but perfectly logical). Would it be harmful to still check for those
>> standard locations whenever no explicit location is given be harmful (other
>> than itching the SecurityManager)?
>>
>> So if I understand correctly, we *also* need to use PrivilegedActions.
>> Does it boils down to wrapping system calls in
>> AccessController.doPrivileged() calls? Where and how are those calls
>> authorized? Sorry, I never used the PrivilegedActions and SecurityManager
>> paradigm yet. If you have some good pointers or suggestions...
>>
>> I don't really understand either why we're speaking of the CWD whereas
>> all the VelocityView knows is the webapp root. But I may have missed
>> something.
>>
>>
>>   Claude
>>
>> On 21/03/2018 22:23, Nathan Bubna wrote:
>>
>>> If we're talking 2.x, then adding a PrivilegedAction sounds better.  If
>>> 3.0
>>> (which, i think needs to happen anyway, right Claude?), then i'd agree
>>> with
>>> Michael. The auto config would be better off as something users need to
>>> explicitly turn on, not the default any longer.
>>>
>>> On Wed, Mar 21, 2018 at 2:03 PM, Michael Osipov <micha...@apache.org>
>>> wrote:
>>>
>>> Am 2018-03-21 um 06:17 schrieb Christopher Schultz:
>>>>
>>>> All,
>>>>>
>>>>> Using velocity-tools 2.0.
>>>>>
>>>>> I've been exploring what it takes to get my application working under a
>>>>> SecurityManager and it seems that o.a.v.t.view.VelocityView tries to
>>>>> load a few configuration files from their default locations even when a
>>>>> specific configuration file has been specified by a subclass like
>>>>> VelocityLayoutServlet:
>>>>>
>>>>> 
>>>>>   velocity
>>>>>   
>>>>> com.chadis.web.servlet.VelocityLayoutServlet
>>>>>   
>>>>>
>>>>>   
>>>>> org.apache.velocity.tools
>>>>> /WEB-INF/tools.xml
>>>>>   
>>>>> ...
>>>>>
>>>>>
>>>>> What ends up happening is that VelocityView checks for the default
>>>>> configuration files tools.xml and tools.properties (in the current
>>>>> working directory) and so FilePermissions must be given to the whole
>>>>> JVM
>>>>> -- because VelocityView (or ConfigurationUtils) doesn't make the
>>>>> attempt
>>>>> in a PrivilegedAction.
>>>>>
>>>>> I think this can be done in a more friendly way, but I'm not sure what
>>>>> is best for the community.
>>>>>
>>>>> We could add a PrivilegedAction to the mix when a SecurityManager is
>>>>> present. This way, the velocity library could be granted read access to
>>>>> these specific files (instead of the whole JVM). This would impact the
>>>>> smallest number of users.
>>

Re: [tools] Running under a SecurityManager

[Nathan Bubna]

If we're talking 2.x, then adding a PrivilegedAction sounds better.  If 3.0
(which, i think needs to happen anyway, right Claude?), then i'd agree with
Michael. The auto config would be better off as something users need to
explicitly turn on, not the default any longer.

On Wed, Mar 21, 2018 at 2:03 PM, Michael Osipov  wrote:

> Am 2018-03-21 um 06:17 schrieb Christopher Schultz:
>
>> All,
>>
>> Using velocity-tools 2.0.
>>
>> I've been exploring what it takes to get my application working under a
>> SecurityManager and it seems that o.a.v.t.view.VelocityView tries to
>> load a few configuration files from their default locations even when a
>> specific configuration file has been specified by a subclass like
>> VelocityLayoutServlet:
>>
>>
>>  velocity
>>  
>>com.chadis.web.servlet.VelocityLayoutServlet
>>  
>>
>>  
>>org.apache.velocity.tools
>>/WEB-INF/tools.xml
>>  
>>...
>>
>>
>> What ends up happening is that VelocityView checks for the default
>> configuration files tools.xml and tools.properties (in the current
>> working directory) and so FilePermissions must be given to the whole JVM
>> -- because VelocityView (or ConfigurationUtils) doesn't make the attempt
>> in a PrivilegedAction.
>>
>> I think this can be done in a more friendly way, but I'm not sure what
>> is best for the community.
>>
>> We could add a PrivilegedAction to the mix when a SecurityManager is
>> present. This way, the velocity library could be granted read access to
>> these specific files (instead of the whole JVM). This would impact the
>> smallest number of users.
>>
>> We could remove the attempts to load these configuration files out of
>> the CWD. This would probably affect the largest number of users
>> (although relying on the CWD to find a default configuration file is ...
>> bad practice).
>>
>> Or we could change the way Velocity*Servlet use VelocityView so that
>> default configuration files are only loaded when there is no explicit
>> configuration file.
>>
>> Thoughts?
>>
>
> Personally, I was never a huge fan of this autoconfig. It was overly
> comples. A few only understood. This also lead to subtile bugs which Maven
> Doxia leaving them open for years which I finally fixed last year.
>
> I would personally expact an empty toolbox present, if nothing has been
> configured by the user. Even if this will break stuff, we can do so for 3.0
> with ease. See https://issues.apache.org/jira/browse/DOXIASITETOOLS-93.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Yet another issue cleanup

[Nathan Bubna]

On Fri, Dec 8, 2017 at 2:54 PM, Michael Osipov  wrote:

> Hi folks,
>
> I have noticed that good bunch of Velocity 0 tickets have been rejected
> though fix version has been set. This is confusing for me and likely
> others. Any reasoning behind this? Fix version implies that this one is
> fixed at some point, not rejected for version x.
>
> Any objections to clean that up?
>

+1


> Another one, does anyone mind to remove non-released 1.7 versions and
> consolidate them into 1.7.x just like on the Subversion repo?
>

+1

Re: JIRA permissions

[Nathan Bubna]

Ah, seems there's two of you in JIRA (or at least two guys w/your name).
I'd only put the [wrong] one. :)

On Fri, Dec 8, 2017 at 12:27 PM, Nathan Bubna <nbu...@gmail.com> wrote:

> I think i did add you to VELOCITY also. I'll double check.
>
> On Fri, Dec 8, 2017 at 12:21 PM, Michael Osipov <micha...@apache.org>
> wrote:
>
>> Am 2017-12-08 um 16:00 schrieb Nathan Bubna:
>>
>>> Claude i think you should have the karma, if i'm reading things right;
>>> you
>>> were already in the Administrators role. Michael, you are now too.
>>>
>>> If i'm wrong, do let me know. We'll figure it out.
>>>
>>
>> Just rechecked. The role applies to VELTOOLS only. Can we have this for
>> VELOCITY too?
>>
>> Michael
>>
>
>

Re: JIRA permissions

[Nathan Bubna]

I think i did add you to VELOCITY also. I'll double check.

On Fri, Dec 8, 2017 at 12:21 PM, Michael Osipov <micha...@apache.org> wrote:

> Am 2017-12-08 um 16:00 schrieb Nathan Bubna:
>
>> Claude i think you should have the karma, if i'm reading things right; you
>> were already in the Administrators role. Michael, you are now too.
>>
>> If i'm wrong, do let me know. We'll figure it out.
>>
>
> Just rechecked. The role applies to VELTOOLS only. Can we have this for
> VELOCITY too?
>
> Michael
>

Re: JIRA permissions

[Nathan Bubna]

Claude i think you should have the karma, if i'm reading things right; you
were already in the Administrators role. Michael, you are now too.

If i'm wrong, do let me know. We'll figure it out.

On Fri, Dec 8, 2017 at 6:52 AM, Nathan Bubna <nbu...@gmail.com> wrote:

> Good idea. I'll see what i can do.
>
> On Fri, Dec 8, 2017 at 5:54 AM, Claude Brisson <cla...@renegat.net.invalid
> > wrote:
>
>> I don't have enough karma, but we should hear from Nathan.
>>
>> Also, I wouldn't mind being a JIRA admin on those projects...
>>
>>   Claude
>>
>>
>>
>> On 08/12/2017 14:03, Michael Osipov wrote:
>>
>>> Hi folks,
>>>
>>> can someone give me the permissions to administer VELOCITY and VELTOOLS?
>>> I'd like to clean up very old open issues and focus and Velocity Tools 3.0.
>>>
>>> Michael
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>
>>
>

Re: JIRA permissions

[Nathan Bubna]

Good idea. I'll see what i can do.

On Fri, Dec 8, 2017 at 5:54 AM, Claude Brisson 
wrote:

> I don't have enough karma, but we should hear from Nathan.
>
> Also, I wouldn't mind being a JIRA admin on those projects...
>
>   Claude
>
>
>
> On 08/12/2017 14:03, Michael Osipov wrote:
>
>> Hi folks,
>>
>> can someone give me the permissions to administer VELOCITY and VELTOOLS?
>> I'd like to clean up very old open issues and focus and Velocity Tools 3.0.
>>
>> Michael
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [ANNOUNCE] Apache Velocity Engine 2.0

[Nathan Bubna]

On Sat, Aug 12, 2017 at 8:50 AM, Michael Osipov  wrote:

> Am 2017-08-09 um 12:52 schrieb Claude Brisson:
>
>> The Apache Velocity community is pleased to announce the release of
>> Apache Velocity Engine 2.0. The release is available for download at:
>>
>>https://velocity.apache.org/download.cgi#engine
>>
>> Apache Velocity is well-known in the Java field as a lightweight,
>> easy-to-use templating library for creating dynamic web sites and
>> performing other text-generation tasks. It relies on the Velocity Template
>> Language (VTL) which is aimed at ease-of-use and simplicity.
>>
>> This major release introduces several consistent changes and new
>> features, including:
>>
>> - Switch to the SLF4J logging facade.
>> - Configurable whitespace gobbling, that lets template writers indent
>> their templates without polluting the output.
>> - VTL Method arguments and array subscripts can now be arithmetic
>> expressions.
>> - Configurable method arguments conversion handler, which by default
>> handles automatic conversions between booleans, numbers, strings and enums.
>> - Significant reduction of the memory consumption.
>> - JSR-223 Scripting Engine implementation.
>> - Made Velocity OSGi-ready.
>>
>
> Claude,
>
> thank you for the hard work and great collaboration on this.
>

+1 Thank you both for all your work on this!

Re: release is ready

[Nathan Bubna]

It's here:

http://repo1.maven.org/maven2/org/apache/velocity/velocity-engine-core/2.0/

But we should probably mention the new maven path in the upgrading docs.

On Tue, Aug 8, 2017 at 12:52 PM, Alex Fedotov  wrote:

> 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 website now shows engine 2.0 documentation.
> >
> > I think the release is ready to be announced on the users list (and other
> > channels?).
> >
> > Can some of you please check that I didn't forget anything important and
> > that links are correctly working?
> >
> > Thanks.
> >
> >   Claude
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > For additional commands, e-mail: dev-h...@velocity.apache.org
> >
> >
>

Re: release is ready

[Nathan Bubna]

The links all look good to me, nor can i think of anything missing at this
point.

On Sun, Aug 6, 2017 at 11:01 AM, Claude Brisson  wrote:

> The maven artefact has been publish, the release is visible on apache
> mirrors, and the website now shows engine 2.0 documentation.
>
> I think the release is ready to be announced on the users list (and other
> channels?).
>
> Can some of you please check that I didn't forget anything important and
> that links are correctly working?
>
> Thanks.
>
>   Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Engine 2.0 RC9 Release quality

[Nathan Bubna]

[+1] GA

On Fri, Jul 28, 2017 at 4:00 PM, Claude Brisson  wrote:

> The Velocity Engine 2.0 RC9 is available.
>
> Main change since the RC8 is a full review of the DataSourceResourceLoader.
>
> Release notes:
>
> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
> ine/2.0/release-notes.html
>
> Distribution:
>
>  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
> Maven 2 staging repository:
>
>  * https://repository.apache.org/content/repositories/orgapache
> velocity-1020
>
> If you have had a chance to review the test build, please respond with a
> vote on its quality:
>
>  [ ] Leave at test build
>  [ ] Alpha
>  [ ] Beta
>  [ ] General Availability (GA)
>
>   Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Engine 2.0 RC8 Release quality

[Nathan Bubna]

On Mon, May 1, 2017 at 9:50 AM, Claude Brisson  wrote:

>  [ ] Leave at test build
>  [ ] Alpha
>  [ ] Beta
>  [X ] General Availability (GA)
>

Re: Velocity truth

[Nathan Bubna]

On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov <micha...@apache.org> wrote:

> Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
>
>> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <micha...@apache.org>
>> wrote:
>>
>>> 7) check object for a length() or size() method, if so return whether it
>>>
>>>> returns 0, but I agree with Alex Fedotov that we could skip those
>>>> methods if we already took care for strings and collections.
>>>>
>>>>
>>> What happened to array#length? You completely missed that out.
>>> I would not drop #length() and #size(), you'd ultimately fail with
>>> javax.naming.directory.Attribute#size() or
>>> javax.naming.directory.Attributes#size().
>>> There are likely more examples to have this.
>>>
>>
>>
>> i don't think it hurts to keep them, most users won't often get that far,
>> i
>> think.
>>
>
> I did not say we should drop them, I said that they are crucial in some
> situations. Dropping them would be wrong.



Yup. I was agreeing. :)


> 8) If directive.if.tostring.check = false, stop here and return true (*)
>>
>>>
>>>> 9) check object for a toString() method, and return whether the string
>>>> is non-null and non-empty
>>>>
>>>> The 6th step won't be reached very often...
>>>>
>>>> (*) the old configuration parameter was directive.if.tostring.nullchec
>>>> k,
>>>> but for consistency with the new behavior regarding empty strings, my
>>>> proposal is to rename it like this. I don't consider that backward
>>>> compatibility is important since all collections are handled above in
>>>> the chain.
>>>>
>>>>
>>> 9) is somewhat confusing because #toString() is never null unless you
>>> override it and return a custom string. Moreover, how will a #toString()
>>> guarantee you that an object is logically empty? It can't, see
>>> javax.naming.directory.SearchResult#getAttributes().
>>>
>>> At best, this would be false by default in 2.0.
>>>
>>
>> ...
>>
>> I still back this check. Velocity is for templating, text output, i.e. a
>> display language. Velocity-specific classes (including some VelocityTools)
>> have had cause in the past to return null or empty strings specifically
>> because of this check and that toString() is regularly central to
>> rendering
>> objects. While it cannot guarantee emptiness for every object out there,
>> it
>> is a sensible check. The goal here is not perfection, but to catch common
>> cases, and due to history, i believe this is a common one.
>>
>
> Again, there might be cases this is necessary though I cannot make up one
> from the top of my head. I am just saying that this should not be a default
> setting and people must know what they enable at the end.


My concern was backward compatibility, which, while not necessary, is still
quite valuable. There are existing VelocityTools that rely on this, after
all. Given all the ways to avoid getting to this check, i don't see the
compelling reason to toggle the default here. Though, as always, i will
defer to those doing actual work right now. :) Just chiming in with my two
bits.

Re: Velocity truth

[Nathan Bubna]

On Mon, Feb 6, 2017 at 7:48 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Claude,

...

> > $obj returns false from getAsBoolean() (provided there is such a method)
>
> $obj is empty string (CharSequence w/length 0)
> > $obj returns true from isEmpty() (provided there is such a method)
> > $obj is array of length 0
> > $obj returns null from getAsNumber() (provided there is such a method)
> > $obj returns 0 from length() or size() (provided there is such a method)
> > $obj returns empty string from toString() (provided there is such a
> method)
> >
> > Also, I noticed that Velocity weren't very consistent with literals. The
> > only literal returning true is the 'true' literal. "foo" is false,
> > whereas it should be consistent with $foo containing "foo".
>
> Can we maybe make an exception for Collections? Maybe for a Collection
> (or array), we never call toString() on it? [].toString will always give
> you garbage (which will be truthy) and Collection.toString() will also
> likely give you garbage and it will also always be truthy unless it's
> (a) null or (b) the Collection implements toString in a surprising way
> relative to java.util Collections.
>
...

Yeah, one of the crucial ideas here is that Velocity would stop checking as
soon as it found one of these. So no Array, CharSequence, or Collection
would ever make it down the lookup chain to toString(). The goal is to be
more type/function aware specifically to avoid getting down to the
toString(), but still leaving that toString() check for better backward
compatibility.

Re: Velocity truth

[Nathan Bubna]

On Mon, Jan 30, 2017 at 1:33 PM, Claude Brisson <cla...@renegat.net> wrote:

> On 30/01/2017 22:08, Nathan Bubna wrote:
>
> On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson <cla...@renegat.net>
>> wrote:
>>
>> On 28/01/2017 20:23, Alex Fedotov wrote:
>>>
>>> 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 toString for debugging
>>>> purposes and produce very long  strings (including nested objects,
>>>> etc.).
>>>> In the code above that would be a huge inefficiency.
>>>>
>>>> I totally agree that a great percentage of #if($foo) statements are just
>>> here to check for nulls. And the current behavior of returning false for
>>> empty strings, empty arrays and empty maps could already be problematic
>>> in
>>> this regard
>>>
>>> And I think I have a good proposal about that.
>>>
>>> Since
>>>
>>> $foo differenciate null and "" (by displaying the first and not the
>>> second)
>>> $!foo assimilates null and "" (by hiding both)
>>>
>>> why not consider that:
>>>
>>> #if($foo) returns false for null and true for everything else, and
>>> #if($!foo) returns false for null, "", zero, empty arrays, etc...
>>>
>>> Yikes. That looks like a scary combo of significant and subtle. It would
>> need to be well-highlighted in the release notes, change logs, docs, etc.
>>
>> I might like it. Maybe. I dunno. The syntax is giving my tired brain
>> spasms, given that it's close to the very different #if( !$foo ). I can't
>> "read" it, if that make sense. It's like a complex regexp, where i have to
>> think my way through it, instead of just reading it.
>>
>> Is there a use-case for having both supported in the same template?
>> Otherwise, it might be better to avoid the subtlety and just support a
>> configuration property for how clever templates can be with evaluating
>> #if(
>> $foo ).
>>
>> Maybe we do the full lookup chain by default, but let people set a
>>
>> directive.if.emptycheck = false
>>
>> That would limit it to just checking for false or null values (presumably
>> still including getAsBoolean, getAsString, and toString), but skipping the
>> "empty" checks.
>>
>> Then the high performance move is:
>>
>> directive.if.emptycheck = false
>> directive.if.tostring.nullcheck = false
>>
>> But the default is for both to be true.
>>
>> That should be enough, yes.
>
> I like this syntax trick, but it remains a trick, so I won't stand for it.
> Let's forget it.
>
> However, I wonder if we should rework the lookup chain so that it never
> reaches bottom methods for standard types, collections and arrays. The
> lookup chain may pretty well mix false and true checks. Like: if it's an
> array, return whether or not it's empty and don't go further.


Good idea.  Once we find a method for checking (whether for null, false, or
empty), then we should take its answer and go no further in the chain.

Re: Velocity truth

[Nathan Bubna]

On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson <cla...@renegat.net> wrote:

> On 28/01/2017 20:23, Alex Fedotov wrote:
>
> 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 toString for debugging
>> purposes and produce very long  strings (including nested objects, etc.).
>> In the code above that would be a huge inefficiency.
>>
>
> I totally agree that a great percentage of #if($foo) statements are just
> here to check for nulls. And the current behavior of returning false for
> empty strings, empty arrays and empty maps could already be problematic in
> this regard
>
> And I think I have a good proposal about that.
>
> Since
>
> $foo differenciate null and "" (by displaying the first and not the second)
> $!foo assimilates null and "" (by hiding both)
>
> why not consider that:
>
> #if($foo) returns false for null and true for everything else, and
> #if($!foo) returns false for null, "", zero, empty arrays, etc...
>

Yikes. That looks like a scary combo of significant and subtle. It would
need to be well-highlighted in the release notes, change logs, docs, etc.

I might like it. Maybe. I dunno. The syntax is giving my tired brain
spasms, given that it's close to the very different #if( !$foo ). I can't
"read" it, if that make sense. It's like a complex regexp, where i have to
think my way through it, instead of just reading it.

Is there a use-case for having both supported in the same template?
Otherwise, it might be better to avoid the subtlety and just support a
configuration property for how clever templates can be with evaluating #if(
$foo ).

Maybe we do the full lookup chain by default, but let people set a

directive.if.emptycheck = false

That would limit it to just checking for false or null values (presumably
still including getAsBoolean, getAsString, and toString), but skipping the
"empty" checks.

Then the high performance move is:

directive.if.emptycheck = false
directive.if.tostring.nullcheck = false

But the default is for both to be true.




>   Claude
>
>
>> Alex
>>
>> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nbu...@gmail.com> wrote:
>>
>> 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.
>>>
>>> As for the literals, the thought of them being used in #if statements in
>>> a
>>> template language is cringe-inducing. What's the use-case? Temporary
>>> debugging hacks? If so, part of me thinks maybe only 'true' should even
>>> be
>>> allowed.
>>>
>>> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cla...@renegat.net>
>>> wrote:
>>>
>>>
>>>> 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
>>>>> assignee. You never know who handled it without reading the entire
>>>>> thread. A ticket should always have an assignee if code has been
>>>>>
>>>> changed.
>>>
>>>>
>>>>> Here's what had been specified by Nathan at the time (order is
>>>>
>>> meaningful,
>>>
>>>> and falseness seems easier to specify than truth):
>>>>
>>>> $obj is null
>>>> $obj is boolean false
>>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>>> $obj is empty string (CharSequence w/length 0)
>>>> $obj returns true from isEmpty() (provided there is such a method)
>>>> $obj is array of length 0
>>>> $obj returns null from getAsString() (provided there is such a method)
>>>> $obj returns empty string from getAsString() (provided there is such a
>>>>

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

[Nathan Bubna]

On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna <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.
>>
>
> Seems reasonable, and also familiar; this may have been discussed before.
>

Oh, yes, and built. I knew this was familiar. :)

See http://velocity.apache.org/engine/2.0/configuration.html :

directive.if.tostring.nullcheck = true


>
>> 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 toString for debugging
>> purposes and produce very long  strings (including nested objects, etc.).
>> In the code above that would be a huge inefficiency.
>>
>
> Yes, that's part of the motive to have this lookup chain. If there's a
> match higher up, toString() is avoided. Big deal for maps and arrays.
>
>
>>
>> Alex
>>
>> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nbu...@gmail.com> wrote:
>>
>> > 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.
>> >
>> > As for the literals, the thought of them being used in #if statements
>> in a
>> > template language is cringe-inducing. What's the use-case? Temporary
>> > debugging hacks? If so, part of me thinks maybe only 'true' should even
>> be
>> > allowed.
>> >
>> > On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cla...@renegat.net>
>> > wrote:
>> >
>> > >
>> > >
>> > >>>> 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
>> > >> assignee. You never know who handled it without reading the entire
>> > >> thread. A ticket should always have an assignee if code has been
>> > changed.
>> > >>
>> > >>
>> > > Here's what had been specified by Nathan at the time (order is
>> > meaningful,
>> > > and falseness seems easier to specify than truth):
>> > >
>> > > $obj is null
>> > > $obj is boolean false
>> > > $obj returns false from getAsBoolean() (provided there is such a
>> method)
>> > > $obj is empty string (CharSequence w/length 0)
>> > > $obj returns true from isEmpty() (provided there is such a method)
>> > > $obj is array of length 0
>> > > $obj returns null from getAsString() (provided there is such a method)
>> > > $obj returns empty string from getAsString() (provided there is such a
>> > > method)
>> > > $obj returns null from getAsNumber() (provided there is such a method)
>> > > $obj returns 0 from length() or size() (provided there is such a
>> method)
>> > > $obj returns empty string from toString() (provided there is such a
>> > method)
>> > >
>> > > Regarding this spec:
>> > >  - I'm not sure about getAsString() ; toString() is usually the
>> standard
>> > > way of getting the String representation and should be enough.
>> > >  - I'm not convinced by the fact that zero should be true. I hear
>> > Nathan's
>> > > point that for a display language, zero is as legitimate as any other
>> > > number to be displayed. But it breaks the principle of least surprise,
>> > > since each and every other language around, when not forbidding number
>> > > towards boolean implicit conversion, consider zero as false.
>> > >
>> > > So I'd rather go with:
>> > >
>> > > $obj is null
>> > > $obj is Boolean false
>> > > $obj is Number zero (whatever Number variant)
>> > > $obj returns false from getAsBoolean() (provided there is such a
>> method)
>> > > $obj is empty string (CharSequence w/length 0)
>> > > $obj returns true from isEmpty() (provided there is such a method)
>> > > $obj is array of length 0
>> > > $obj returns null from getAsNumber() (provided there is such a method)
>> > > $obj returns 0 from length() or size() (provided there is such a
>> method)
>> > > $obj returns empty string from toString() (provided there is such a
>> > method)
>> > >
>> > > Also, I noticed that Velocity weren't very consistent with literals.
>> The
>> > > only literal returning true is the 'true' literal. "foo" is false,
>> > whereas
>> > > it should be consistent with $foo containing "foo".
>> > >
>> > >   Claude
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> > > For additional commands, e-mail: dev-h...@velocity.apache.org
>> > >
>> > >
>> >
>>
>
>

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

[Nathan Bubna]

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.
>

Seems reasonable, and also familiar; this may have been discussed before.


> 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 toString for debugging
> purposes and produce very long  strings (including nested objects, etc.).
> In the code above that would be a huge inefficiency.
>

Yes, that's part of the motive to have this lookup chain. If there's a
match higher up, toString() is avoided. Big deal for maps and arrays.


>
> Alex
>
> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nbu...@gmail.com> wrote:
>
> > 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.
> >
> > As for the literals, the thought of them being used in #if statements in
> a
> > template language is cringe-inducing. What's the use-case? Temporary
> > debugging hacks? If so, part of me thinks maybe only 'true' should even
> be
> > allowed.
> >
> > On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cla...@renegat.net>
> > wrote:
> >
> > >
> > >
> > >>>> 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
> > >> assignee. You never know who handled it without reading the entire
> > >> thread. A ticket should always have an assignee if code has been
> > changed.
> > >>
> > >>
> > > Here's what had been specified by Nathan at the time (order is
> > meaningful,
> > > and falseness seems easier to specify than truth):
> > >
> > > $obj is null
> > > $obj is boolean false
> > > $obj returns false from getAsBoolean() (provided there is such a
> method)
> > > $obj is empty string (CharSequence w/length 0)
> > > $obj returns true from isEmpty() (provided there is such a method)
> > > $obj is array of length 0
> > > $obj returns null from getAsString() (provided there is such a method)
> > > $obj returns empty string from getAsString() (provided there is such a
> > > method)
> > > $obj returns null from getAsNumber() (provided there is such a method)
> > > $obj returns 0 from length() or size() (provided there is such a
> method)
> > > $obj returns empty string from toString() (provided there is such a
> > method)
> > >
> > > Regarding this spec:
> > >  - I'm not sure about getAsString() ; toString() is usually the
> standard
> > > way of getting the String representation and should be enough.
> > >  - I'm not convinced by the fact that zero should be true. I hear
> > Nathan's
> > > point that for a display language, zero is as legitimate as any other
> > > number to be displayed. But it breaks the principle of least surprise,
> > > since each and every other language around, when not forbidding number
> > > towards boolean implicit conversion, consider zero as false.
> > >
> > > So I'd rather go with:
> > >
> > > $obj is null
> > > $obj is Boolean false
> > > $obj is Number zero (whatever Number variant)
> > > $obj returns false from getAsBoolean() (provided there is such a
> method)
> > > $obj is empty string (CharSequence w/length 0)
> > > $obj returns true from isEmpty() (provided there is such a method)
> > > $obj is array of length 0
> > > $obj returns null from getAsNumber() (provided there is such a method)
> > > $obj returns 0 from length() or size() (provided there is such a
> method)
> > > $obj returns empty string from toString() (provided there is such a
> > method)
> > >
> > > Also, I noticed that Velocity weren't very consistent with literals.
> The
> > > only literal returning true is the 'true' literal. "foo" is false,
> > whereas
> > > it should be consistent with $foo containing "foo".
> > >
> > >   Claude
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > > For additional commands, e-mail: dev-h...@velocity.apache.org
> > >
> > >
> >
>

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

[Nathan Bubna]

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.

As for the literals, the thought of them being used in #if statements in a
template language is cringe-inducing. What's the use-case? Temporary
debugging hacks? If so, part of me thinks maybe only 'true' should even be
allowed.

On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson  wrote:

>
>
 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
>> assignee. You never know who handled it without reading the entire
>> thread. A ticket should always have an assignee if code has been changed.
>>
>>
> Here's what had been specified by Nathan at the time (order is meaningful,
> and falseness seems easier to specify than truth):
>
> $obj is null
> $obj is boolean false
> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsString() (provided there is such a method)
> $obj returns empty string from getAsString() (provided there is such a
> method)
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)
>
> Regarding this spec:
>  - I'm not sure about getAsString() ; toString() is usually the standard
> way of getting the String representation and should be enough.
>  - I'm not convinced by the fact that zero should be true. I hear Nathan's
> point that for a display language, zero is as legitimate as any other
> number to be displayed. But it breaks the principle of least surprise,
> since each and every other language around, when not forbidding number
> towards boolean implicit conversion, consider zero as false.
>
> So I'd rather go with:
>
> $obj is null
> $obj is Boolean false
> $obj is Number zero (whatever Number variant)
> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)
>
> Also, I noticed that Velocity weren't very consistent with literals. The
> only literal returning true is the 'true' literal. "foo" is false, whereas
> it should be consistent with $foo containing "foo".
>
>   Claude
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

[VOTE] Michael Osipov as committer

[Nathan Bubna]

Hey folks,

Michael Osipov has been rigorously and vigorously reviewing the progress of
Engine 2.0, with commits specific and knowledgeable to be nigh
indistinguishable from code itself. He's already an ASF committer (with
Maven at least, maybe Jersey too?). In any case, he knows our ways and is
actively contributing to Velocity. When a contributor starts keeping a
committer busy (hang in there, Claude), we reward them with commit access
so they can do it themselves. :)

What say ye?


[ ] +1 Sounds good.
[ ] +/- 0 Not sure, because...
[ ] -1 No. Because...

My vote is +1

Vote ends in about three days (sometime Monday).

Re: ApacheCon NA 2017

[Nathan Bubna]

On Wed, Jan 4, 2017 at 7:57 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I'm going to be in Miami for this year's ApacheCon. In all the years
> I've been going to ApacheCons, I've never seen a single presentation on
> Velocity. That probably has something to do with the following:
>
> 1. Until recent work, it's been a "mature" project (no excitement)
> 2. It's not particularly sexy; it gets the job done
>
> Are there any topics anyone has been considering presenting anytime
> recently? Even something like "what's new in Velocity 2"? I'd certainly
> like to (a) breathe new life into the community and (b) meet some
> members of said community. A talk at ApacheCon can help out a lot with
> that.
>

I haven't heard of any. I know Henning used to do talks on Velocity (i
replaced him once at OSCON). I do think a talk is a great idea, especially
with all Claude's work toward a new release.


> I'll already be presenting at least one talk on Tomcat. I'd be happy to
> work with someone to develop a presentation that promotes the Velocity
> community in some way.
>
> I've been a committer in name only for quite a few years, mostly because
> of the maturity of this project (my work wasn't really required), so
> perhaps I'm not the best choice for a subject-matter expert. But I'm
> perfectly happy to stand up in front of people and talk about technology.
>

Knowing Velocity, being a longtime part of the dev community, and being
willing to talk about it in front of people make you nearly as good a
choice as anyone.


> Is anyone else planning to attend? Would anyone be willing to present?
>

Alas, not i.


> Thanks,
> -chris
>
>

Re: svn commit: r1776916 [1/2] - in /velocity/tools/trunk: ./ src/changes/ velocity-tools-assembly/ velocity-tools-assembly/src/main/assembly/ velocity-tools-examples/velocity-tools-examples-showcase/

[Nathan Bubna]

Wow. Sounds great, Claude!

On Mon, Jan 2, 2017 at 2:49 AM,  wrote:

> Author: cbrisson
> Date: Mon Jan  2 10:49:55 2017
> New Revision: 1776916
>
> URL: http://svn.apache.org/viewvc?rev=1776916=rev
> Log:
> [tools] ImportTool and XmlTool reenginering, along with the addition of a
> JsonTool.
>
> The XmlTool now uses the standard JRE parser rather than the external jdom
> library. Thus, the velocity-tools-xml module has been removed, and XmlTool
> has been incorporated to the generic and view modules.
>
> ImportTool and ImportSupport have been splitted between the generic and
> the view packages, as detailed below. The terminology used by the
> ImportSupport has been reviewed (use local/remote URL instead of
> 'absolute'/'relative' URL).
>
> The generic.ImportSupport and view.ViewImportSupport classes give a basic
> API for:
>  - reading a local resource FIRST from a File (generic version) or from
> the webapp (view version), THEN, if not found from the classpath.
>  - fetching a local URL (only applicable for the view version), which
> allows to mix several J2EE view technologies in the same container.
>  - fetching a remote URL (which is forbidden in safe mode for the view
> version).
>
> generic.ImportTool and view.ImportTool expose read(String resource) and
> fetch(String url) methods, based on the ImportSupport and ViewImportSupport
> APIs.
>
> generic.XmlTool and view.XmlTool expose parse(String xml), read(String
> xmlResource) and fetch(String url) methods, based on the ImportSupport and
> ViewImportSupport APIs. Both accept the 'resource=' and
> 'source=' configuration parameters.
>
> generic.JsonTool and view.JsonTool expose parse(String json), read(String
> jsonResource) and fetch(String url) methods, based on the ImportSupport and
> ViewImportSupport APIs. Both accept the 'resource=' and
> 'source=' configuration parameters.
>
> Whenever no specific configuration source has been given, view.XmlTool and
> view.JsonTool add the ability to parse the posted request body, if it
> corresponds to an xml or json mime type.
>
> Some remarks about the implementation:
>  - I choosed to shade the org.json library, to avoid another dependency.
>  - The XmlUtils class provides a static pool of xml parsers along with
> several xml utilities
>  - feel free to make alternate proposals for the tools API and
> configuration ; in particular, for the the "resource=" and
> "source=" terminology.
>
> Happy new year, by the way.
>
>
> Added:
> velocity/tools/trunk/velocity-tools-examples/velocity-tools-
> examples-showcase/src/main/webapp/json.vm
> velocity/tools/trunk/velocity-tools-examples/velocity-tools-
> examples-showcase/src/main/webapp/post_json.vm
> velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/XmlUtils.java
> velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/ImportSupport.java
> velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/ImportTool.java
>   - copied, changed from r1770862, velocity/tools/trunk/velocity-
> tools-view/src/main/java/org/apache/velocity/tools/view/ImportTool.java
> velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/JsonTool.java
> velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/XmlTool.java
> velocity/tools/trunk/velocity-tools-generic/src/test/java/
> org/apache/velocity/tools/generic/JsonToolTests.java
>   - copied, changed from r1770862, velocity/tools/trunk/velocity-
> tools-generic/src/test/java/org/apache/velocity/tools/
> generic/ClassToolTests.java
> velocity/tools/trunk/velocity-tools-generic/src/test/java/
> org/apache/velocity/tools/generic/XmlToolTests.java
> velocity/tools/trunk/velocity-tools-generic/src/test/
> resources/file.xml
> velocity/tools/trunk/velocity-tools-generic/src/test/
> resources/foo.json
> velocity/tools/trunk/velocity-tools-view/src/main/java/org/
> apache/velocity/tools/view/JsonTool.java
> velocity/tools/trunk/velocity-tools-view/src/main/java/org/
> apache/velocity/tools/view/ViewImportSupport.java
>   - copied, changed from r1776915, velocity/tools/trunk/velocity-
> tools-view/src/main/java/org/apache/velocity/tools/view/ImportSupport.java
> velocity/tools/trunk/velocity-tools-view/src/main/java/org/
> apache/velocity/tools/view/XmlTool.java
> Removed:
> velocity/tools/trunk/velocity-tools-view/src/main/java/org/
> apache/velocity/tools/view/ImportSupport.java
> velocity/tools/trunk/velocity-tools-xml/
> Modified:
> velocity/tools/trunk/pom.xml
> velocity/tools/trunk/src/changes/changes.xml
> velocity/tools/trunk/velocity-tools-assembly/pom.xml
> velocity/tools/trunk/velocity-tools-assembly/src/main/assembly/all.xml
> velocity/tools/trunk/velocity-tools-examples/velocity-tools-
> examples-showcase/pom.xml
> 

Re: [tool] More tools reenginering

[Nathan Bubna]

On Mon, Dec 5, 2016 at 9:49 AM, Sergiu Dumitriu 
wrote:

> I agree with Michael here, this direction is against what "pure"
> Velocity is about. The generic tools shouldn't be allowed to fetch
> random resources off the internet.
>

I'm with Claude here. Making powerful tools available is a good thing. If
we were putting this in Engine, i'd protest. Even in VelocityView, clearly
for webapps, it would seem an inappropriate default. But in GenericTools, i
think it fits fine. They are to be generic, useful. Velocity is not just
about MVC, not just used in applications.


> I'm also against propagating the dependency on DOM4J, a library which
> has been dead for ten years.
>

Well, those who do the work should decide, but if i were doing the work,
yeah, dom4j does smell a little. ;) Though arguably we can hardly be too
critical of old, little-update libraries.


> I'm OK with adding tools for working with JSON and XML, as long as they
> perform safe operations on local data, and use modern libraries for the
> generated data structures (org.json:json and the org.w3c.dom package,
> although it's not very user friendly).
>
> On 12/04/2016 07:57 AM, Michael Osipov wrote:
> > Am 2016-12-02 um 10:01 schrieb Claude Brisson:
> >> Hi.
> >>
> >> On 01/12/2016 21:21, Michael Osipov wrote:
> >>> While I understand you idea, I do think that introducing stuff like
> >>> this a bad idea for several reasons:
> >>>
> >>> 1. Processing of structured, low-level data like XML, JSON, form data
> >>> always belongs to a controller and not to the view layer. The view
> >>> layer should always receive a minimal set of high-level structures to
> >>> do its task.
> >>
> >> I'm well aware of this MVC design paradigm. But the underlying purpose
> >> is the separation of concerns, not the fact that the view should be fed
> >> its data like a baby. View layers have grown up, and pull models have
> >> proven their efficiency. Since they are more lightweight and flexible,
> >> they are far more maintainable.
> >>
> >> More specifically, let say for instance that someone wants to build a
> >> webapp and a native mobile app on a common model layer. He would
> >> typically publish his model in the form of an API returning JSON
> >> structures. They cannot be called low-level, because the raw data model
> >> has already been somehow digested in the API presentation logic. Each
> >> API author is trying to guarantee minimal ergonomics. So if I have, say,
> >> the following JSON:
> >>   { '"books" : [ { "author": "Lewis Caroll", "title": "Alice in
> >> Wonderland" } , { "author":"Saint-Exupéry", "title":"le Petit Prince"
> >> } ] }
> >> what you're saying is that it's not high-level enough for the view? I
> >> can't agree.
> >
> > I do not consider this good application design unless I see a specific
> > case where it truly makes sense. Having a browser/client-only app
> > implies using JavaScript, thus Velocity will be a little of use. E.g.,
> > Sonatype Nexus does that. Render skeleton by Velocity, rest is done in
> JS.
> >
> > In this very example, this is not high-level. High-level for me is a
> > complete abstraction of the serialization format, Java structures only.
> > Pretty much like with Eclipse MOXy or Jackson, they support multiple
> > formats and the templater user/designer does not really care about the
> > format.
> >
> >>> 2. You are turning a template engine into a scripting engine which
> >>> Velocity is not.
> >>
> >> Since a bare scripting engine doesn't know how to do templating, I think
> >> you intended to say that I'm empowering Velocity with scripting
> >> abilities. Well... it's already the case. And another thing: I've seen
> >> environments where people made a complete mess of their view layer
> >> without using a single scripting functionality. My point here is that
> >> although we ought to remain attentive to what the language offers,
> >> trying to limit the features is not the right way to promote the
> >> separation of concerns.
> >
> > I agree here, my concern is rather not to introduce features which will
> > people encourage to abuse Velocity for tasks it has not been designed
> > and knowning that their are better suited tools for this.
> >
> >>> 3. By having opening the door for #read("http..") people will start to
> >>> ask for: How do I set credentials, how do I add request headers, how
> >>> do I add my company's proxy, etc? At the end, you will find yourself
> >>> implementing stuff people have already done several times.
> >>
> >> If I understand correctly, you consider that the existing ImportTool is
> >> already wrongful. The door is already open.
> >
> > Unfortunately, it is.
> >
> >> I already had in mind to disallow absolute URLs in safe mode (which is
> >> on by default) for the view versions. This is already the case for the
> >> actual XmlTool, but not for the ImportTool. My plan is to homogeneize
> >> all that: the XmlTool generic version would be relaxed by my 

Re: [VOTE] 2.0 Release Quality

[Nathan Bubna]

+1 GA

On Wed, Nov 16, 2016 at 7:24 AM, Greg Huber  wrote:

> Thanks, works great for me.
>
> [x] General Availability (GA)
>
> +1 non binding.
>
>
> On 16 November 2016 at 11:51, Claude Brisson  wrote:
>
> > The Velocity Engine 2.0 RC3 test build has been available since the 12th,
> > and the RC4 (which only contains trivial fixes) has just been published.
> >
> > Release notes:
> >
> > * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
> > ine/2.0/release-notes.html
> >
> > Distribution:
> >
> >  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
> >
> > Maven 2 staging repository:
> >
> >  * https://repository.apache.org/content/repositories/orgapache
> > velocity-1013
> >
> > If you have had a chance to review the test build, please respond with a
> > vote on its quality:
> >
> >  [ ] Leave at test build
> >  [ ] Alpha
> >  [ ] Beta
> >  [ ] General Availability (GA)
> >
> > Everyone who has tested the RC3 or the RC4 is invited to vote. Votes by
> > PMC members are considered binding. A vote passes if there are at least
> > three binding +1s and more +1s than -1s.
> >
> >
> >   Claude
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > For additional commands, e-mail: dev-h...@velocity.apache.org
> >
> >
>

Re: [tools] Tools reeng

[Nathan Bubna]

+1 deprecate and refactor away. this all sounds good.

On Thu, Nov 17, 2016 at 10:32 AM, Sergiu Dumitriu  wrote:

> On 11/17/2016 12:58 PM, Claude Brisson wrote:
> > There are several things I'd like to do for the tools before releasing
> > them:
> >
> > 1) deprecate the ConversionTool:
> > - date formatting and parsing methods are redundant with (and less
> > complete than) DateTool ones.
> > - number formatting and parsing methods are redundant with the
> > NumberTool and MathTool ones, and also far less necessary now that a lot
> > of automatic conversions are taken care of.
> > - the only remaining feature is a toStrings() method (which does
> > splitting and optional trimming). A single method does not legitimate
> > the need for a tool, and in a web context, the ParameterTool already
> > does it for GET/POST parameters. Still, we can have the method move
> > elsewhere (but where? Maybe deprecate SortTool and have a CollectionTool
> > do splitting and sorting?).
> >
> > 2) deprecate MathTool number parsing and formatting methods, which are
> > redundant with the NumberTool ones.
> >
> > 3) use explicit format names: numberFormat, timeFormat, dateFormat and
> > timestampFormat, instead of a generic 'format' parameter defaulting to
> > an ubiquitous 'default' value. I'd also like to have the default formats
> > be the international formats used by HTML5 (RFC 3339).
> >
> > 4) On the same subject of formats, I'd also would like to introduce
> > date/time format sniffing (as there are some good algorithms out there
> > that we can borrow). We could maybe do the sniffing once and cache the
> > detected format in the AST (but it should be configurable, and probably
> > default to false).
> >
> > 5) I'm pretty inclined to deprecate AlternatorTool, since all designers
> > now use CSS for this purpose. Plus, we now have #if($foreach.index % 2)
> > for this purpose.
> >
> >
>
> +1 for all of these, as long as they are deprecations, and not direct
> removals.
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Logging configuration

[Nathan Bubna]

+1 for logical names and a configurable base.

On Fri, Nov 11, 2016 at 6:24 AM, Claude Brisson  wrote:

> In fact, the logger name (well, *base* logger name) is configurable. So we
> can both be happy: we can have the default base logger name be
> "org.apache.velocity", as like you say it is more intuitive, and people
> like me willing to shorten it can still tune their config file.
>
> But as I said, I'd rather not use package names for sub-packages, since
> "org.apache.velocity.rendering" is far more understandable than
> "org.apache.velocity.runtime.utils.introspection"...
>
>   Claude
>
>
>
> On 11/11/2016 12:59, Greg Huber wrote:
>
>> Doing only casual debugging,  as long as its intuitive to set the
>> debugging
>> name="foobar" name without having to dip into the code sounds great.  The
>> package name is however the easiest to remember as its from the class you
>> are trying to debug (using attached source jar).
>>
>> Thanks
>>
>> On 11 November 2016 at 11:07, Claude Brisson  wrote:
>>
>> And also velocity.rendering for every rendering error (including
>>> introspector/uberspector). So here's the new list:
>>>
>>>   - velocity for the app/runtime/singleton
>>>   - velocity.event for the event cartridge
>>>   - velocity.directive, and velocity.directive.[directivename]
>>>   - velocity.parser
>>>   - velocity.loader and velocity.loader.[loadername]
>>>   - velocity.macro
>>>   - velocity.rendering (rendering errors other than directive ones,
>>> introspector/uberspector)
>>>
>>> Ah, and allso:
>>>   - velocity.scripting for the JSR223 scripting module
>>>
>>>
>>> plus:
>>>   - velocity.tools
>>>   - velocity.tools.[key]
>>>
>>>
>>>
>>> On 11/11/2016 11:14, Claude Brisson wrote:
>>>
>>> Why not, but it should be done right now to take advantage of the major
 version change.

 I checked quickly, and it seems like all logging backends build the
 loggers hierarchy using namespaces separated with dots, which can be
 class
 names by convention but it is not at all necessary.

 I'd rather not use class names, because the logical hierarchy of modules
 is not always reflected by the factual class hierarchy, and because
 "org.apache.velocity.app.Velocity" is obviously redundant and verbose.
 Not to mention "org.apache.velocity.runtime.r
 esource.util.StringResourceRepositoryImpl"... Plus, we can have some
 logger names reflect runtime objects as directives and loaders.

 Now, to the modules themselves: we could have:

   - velocity for the app/runtime/singleton
   - velocity.event for the event cartridge
   - velocity.directive, and velocity.directive.[directivename]
   - velocity.parser
   - velocity.loader and velocity.loader.[loadername]
   - velocity.macro

 Do you see something else?

 Also, for the tools, we can have velocity.tools for the framework and
 velocity.tools.[toolskey] instead of the tools class (which allows
 custom
 user tools to enter our hierarchy).

 Thoughts?

Claude


 On 10/11/2016 17:18, Mike Kienenberger wrote:

 +1 to using several appropriate functional names if we are picking
> loggers by String rather than by Class.
>
> On Thu, Nov 10, 2016 at 11:11 AM, Claude Brisson 
> wrote:
>
> On 10/11/2016 15:56, Greg Huber wrote:
>>
>> Yes it does when I use name="Velocity"
>>
>>> But as you are using the runtime instance logger its either on or off
>>> for
>>> the whole package.  Using a per class I think enables more filtering
>>> as
>>> you
>>> can name="org.apache.velocity.app" level="DEBUG" purely for this
>>> package
>>> and name="org.apache.velocity" level="WARN" for everything else.
>>>
>>> The reasons we only have one logger are mainly historical. It would
>> certainly be more pertinent to have at least one logger per module,
>> loading,
>> introspection, etc...
>>
>> But I you can filter the log file (in eclipse) so it makes no
>>
>>> difference.
>>>
>>>
>>> Thanks for the velocity upgrade!  Thought it was not being maintained
>>> any
>>> more.
>>>
>>> Well, we're kinda resurrecting...
>>
>>
>> Claude
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>
>> -
>>
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>
>
> -
>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>>> For 

Re: svn commit: r1769055 - in /velocity/tools/trunk: velocity-tools-generic/ velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/ velocity-tools-generic/src/test/java/org/apache/vel

[Nathan Bubna]

On Thu, Nov 10, 2016 at 4:19 AM, Sergiu Dumitriu <sergiu.dumit...@gmail.com>
wrote:

> On 11/10/2016 03:01 AM, cbris...@apache.org wrote:
> > Author: cbrisson
> > Date: Thu Nov 10 08:01:41 2016
> > New Revision: 1769055
> >
> > URL: http://svn.apache.org/viewvc?rev=1769055=rev
> > Log:
> > [tools] a tool should either be Serializable or forbid Session scope
> >
> > Modified: velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/RenderTool.java
> > URL: http://svn.apache.org/viewvc/velocity/tools/trunk/velocity-
> tools-generic/src/main/java/org/apache/velocity/tools/
> generic/RenderTool.java?rev=1769055=1769054=1769055=diff
> > 
> ==
> > --- velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/RenderTool.java (original)
> > +++ velocity/tools/trunk/velocity-tools-generic/src/main/java/
> org/apache/velocity/tools/generic/RenderTool.java Thu Nov 10 08:01:41 2016
> > @@ -31,6 +31,7 @@ import org.apache.velocity.context.Conte
> >  import org.apache.velocity.tools.Scope;
> >  import org.apache.velocity.tools.ToolContext;
> >  import org.apache.velocity.tools.config.DefaultKey;
> > +import org.apache.velocity.tools.config.InvalidScope;
> >
> >  /**
> >   * This tool exposes methods to evaluate the given
> > @@ -103,7 +104,9 @@ import org.apache.velocity.tools.config.
> >   * @author Nathan Bubna
> >   * @version $Revision$ $Date$
> >   */
> > +
> >  @DefaultKey("render")
> > +@InvalidScope(Scope.SESSION)
>
> Is it intended to have an IN-valid scope? What prevents it to be used in
> a session?
>
>
Nothing prevents a user from manually inserting one into their session, but
this annotation bans them from configuring VelocityTools to automatically
insert fresh RenderTools into each session for them.


> >  public class RenderTool extends SafeConfig
> >  {
> >  /**
> >
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [ANNOUNCE] Velocity Engine 2.0 test build available

[Nathan Bubna]

Gah, really wish i had time to help. Keep up the great work, Claude!

On Wed, Nov 9, 2016 at 9:06 AM, Claude Brisson  wrote:

> Ok, I reproduced it. It happens when the method is overloaded with a
> variant that takes no argument.
>
> Guess there will be a third release candidate...
>
>
>
> On 09/11/2016 17:44, Greg Huber wrote:
>
>> It seems to be returning the wrong class name in ClassUtils
>>
>>   method = node.getRuntimeServices().getUberspect().getMethod(o,
>> methodName,
>> params,
>> new Info(node.getTemplateName(), node.getLine(),
>> node.getColumn()));
>>
>> It is returning a method name of .thumbResource() rather than
>> .thumbResource(String, String) and then further down the java reflection
>> throws the java.lang.IllegalArgumentException exception.
>>
>>
>> On 9 November 2016 at 16:09, Claude Brisson  wrote:
>>
>> I cannot reproduce it.
>>>
>>> Is the thumbResource() method overloaded?
>>>
>>> Do you have the full stacktrace?
>>>
>>>
>>> On 09/11/2016 16:50, Greg Huber wrote:
>>>
>>> Hello,

 I am getting an error when a parameter on a method name is null, it says
 "wrong number of arguments at"

 eg :

 $entry.filePath == null

 $myPojo.thumbResource($entry.name, $entry.filePath)

 I get an exception :

 java.lang.IllegalArgumentException: wrong number of arguments at..



 public String thumbResource(String name, String filePath) {
   ...
 }

 I have tried to debug it but it seems to originate in the ASTMethod
 class.
 If i change the variable to be blanks it works ok.








 On 9 November 2016 at 14:50, Claude Brisson  wrote:

 A new test build of Velocity Engine 2.0 is available.

> 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 quality vote is called for this build.
>
> Release notes:
>
> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
> ine/2.0/release-notes.html
>
> Distribution:
>
>* https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
> ine/2.0/
>
> Maven 2 staging repository:
>
>* https://repository.apache.org/content/repositories/orgapache
> velocity-1011/
>
> A vote regarding the quality of this test build will be initiated
> within
> the next couple of days.
>
>
> Regards,
>
> Claude
>
>
> On 07/11/2016 11:06, Claude Brisson wrote:
>
> The test build of Velocity Engine 2.0 is available.
>
>> 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 quality vote is called for this build.
>>
>> Release notes:
>>
>> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
>> ine/2.0/release-notes.html
>>
>> Distribution:
>>
>>* https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
>> ine/2.0/
>>
>> Maven 2 staging repository:
>>
>>* https://repository.apache.org/content/repositories/orgapache
>> velocity-1010/
>>
>> A vote regarding the quality of this test build will be initiated
>> within
>> the next couple of days.
>>
>>
>> Regards,
>>
>> Claude
>>
>>
>>
>>
>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>>
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [tools] status of the velocity-tools-struts module?

[Nathan Bubna]

Yeah, JSP isn't dead yet and i'm sure it still works fine. JSP hasn't
changed that much.

On Tue, Nov 8, 2016 at 1:18 AM, Claude Brisson  wrote:

> Then I'll remove it. New versions of Struts may even have their own tools
> for Velocity I've never heard of. And I'm pretty sure they are happier were
> they are, after all it's the framework which should make use of the tools,
> not the tools which should adapt themselves to the framework...
>
> R.I.P., velocity-tools-struts.
>
> What about velocity-tools-view-jsp? It's probably less prone to
> deprecation, since it only depends on velocity-tools-view, and JSP is still
> alive out there, but I don't even know if the current module is
> functional... I could release it as it is, with a warning in the docs,
> after all tests do pass.
>
>   Claude
>
> On 07/11/2016 17:22, Sergiu Dumitriu wrote:
>
>> On 11/07/2016 05:49 AM, Claude Brisson wrote:
>>
>>> Shall we keep this module active or archive it with Tools 3.0?
>>>
>>> I can ask the question on the Struts dev list, if appropriate.
>>>
>>>Claude
>>>
>>>
>>> It seems to depend on struts 1.x, which has been dead for a long time.
>> I'd say remove this tool for the moment.
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: JIRA release note?

[Nathan Bubna]

I don't see a "Releases" either. Under the "Versions" tab, maybe? I'm not
sure. Wonder if Will is reading, if he doesn't see it, no one does, i think.

On Sun, Nov 6, 2016 at 12:20 PM, Claude Brisson  wrote:

> Hi all.
>
> In the process of releasing engine v2.0, I'm supposed to create a release
> note on JIRA, but although I can browse, create and release versions, I
> don't see any 'Releases' menu entry nor any way to create this release note
> here:
>
> https://issues.apache.org/jira/browse/VELOCITY/?selectedTab=
> com.atlassian.jira.jira-projects-plugin:summary-panel
>
> as described here:
>
> https://confluence.atlassian.com/jira064/creating-release-no
> tes-720412392.html
>
> Did I miss something, or do I lack some karma on Jira?
>
>   Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE][RESULT] Release velocity-master 2

[Nathan Bubna]

+1 Thanks, Claude!

On Fri, Oct 14, 2016 at 8:02 AM, Claude Brisson <cla...@renegat.net> wrote:

> Here's the new release candidate after updating commiters/PMC infos:
>
> https://repository.apache.org/content/repositories/orgapache
> velocity-1001/org/apache/velocity/velocity-master/2/velocity-master-2.pom
>
> 3 binding votes (Sergiu, Nathan, Claude), granted that the small changes
> didn't affect the votes. I publish the artifact.
>
>
>   Claude
>
>
> On 14/10/2016 16:16, Claude Brisson wrote:
>
>> Remove Antonio from the PMC, as he asked to go emeritus.
>>
>> I just checked if I had enough karma to do it myself (editing of
>> private/committers/board/committee-info.txt), and it worked.
>>
>> So no worry, Nathan, nothing to do for you :-)
>>
>>   Claude
>>
>>
>> On 14/10/2016 15:29, Nathan Bubna wrote:
>>
>>> Uh, oh. What do i need to do here? Sorry guys, not meaning to be
>>> slacking.
>>>
>>> On Fri, Oct 14, 2016 at 6:14 AM, Antonio Petrelli <
>>> antonio.petre...@gmail.com> wrote:
>>>
>>> 2016-10-14 14:56 GMT+02:00 Claude Brisson <cla...@renegat.net>:
>>>>
>>>> Ah, and Antonio asked to become emeritus (but the change hasn't been
>>>>> pushed upwards, I think only Nathan can do it).
>>>>>
>>>>> Yep :-)
>>>>
>>>> Antonio
>>>>
>>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: [VOTE] Release velocity-master 2

[Nathan Bubna]

Uh, oh. What do i need to do here? Sorry guys, not meaning to be slacking.

On Fri, Oct 14, 2016 at 6:14 AM, Antonio Petrelli <
antonio.petre...@gmail.com> wrote:

> 2016-10-14 14:56 GMT+02:00 Claude Brisson :
>
> > Ah, and Antonio asked to become emeritus (but the change hasn't been
> > pushed upwards, I think only Nathan can do it).
> >
>
> Yep :-)
>
> Antonio
>

Re: [VOTE] Release velocity-master 2

[Nathan Bubna]

+1

On Tue, Oct 11, 2016 at 5:11 AM, Claude Brisson  wrote:

> Hi.
>
> Before staging the release candidate for velocity-engine, I must first
> release the version 2 of velocity-master.
>
> It only contains a pom.xml with the list of PMCs and devs, and enumerate
> the mailing lists, and can be seen here:
>
> http://svn.apache.org/viewvc/velocity/maven/tags/velocity-ma
> ster-2/pom.xml?revision=1764228=markup
>
> There are two changes from version 1:
>
>  - added Sergiu Dumitriu as a developer
>  - upgraded parent apache pom from v10 to v18
>
> (I don't know where snapshots and prepared releases do land on
> https://repository.apache.org , I was unable to find them on
> https://repository.apache.org after the release:prepare call, which
> apparently went smoothly, maybe there is some delay... or maybe an empty
> parent pom doesn't produce anything...).
>
>
> [ ] +1 Let's do it
> [ ] +0 Have fun; i don't care.
> [ ] -0  Not sure about this, but i won't stop you.
> [ ] -1 No, because __
>
> I'm +1.
>
>
>Claude
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Macro arguments

[Nathan Bubna]

Since you're soliciting opinions, i have to say that we should probably
just fully adopt Java's call-by-sharing semantics and not bother with a
configurable argument evaluation strategy for macros. I suspect that a
shift to call-by-sharing would not break the 90% of macros out there. I
don't have evidence for that, but that's my suspicion. Velocity lives in a
Java world, Java semantics and practices are easily spotted throughout VTL
and VelocityTools as it is. I think the principle of least surprise
dictates call-by-sharing and should make us confident that it will be an
easy transition. Or does anyone actively want some variety of call-by-name
for macros?

Though, of course, y chief opinion here, as it has been for decades, is
that those who do the work make the decision. If you want this to be
configurable, Claude, then go for it.

As to localscope, that's deprecated in 1.7. Recall the move toward
"explicit scope control"? I'm of the opinion that the only "implicit" scope
in VTL should be the global one. Anyone wanting to get/set an exclusively
local variable should do so explicitly (e.g. #set( $macro.foo = 'bar' ) and
$macro.foo ). I do feel fairly strongly on this one, but as i'm not heavily
using Velocity any more, i can hold my peace if things go otherwise. If
you're content with explicit scoping, it is probably worth reconsidering
whether macro.provide.scope.control should still default to false. I was
never quite certain about that default when i implemented it.

And Claude, thanks again for all the work on this. Velocity may not be
critical to my work these days, but it is still good to see it being
updated.

On Tue, Sep 13, 2016 at 11:23 AM, Claude Brisson  wrote:

> It may be the last big subject to address before releasing 2.0: how to
> handle macro arguments?
>
> Those three issues exhibit nasty side effects of the current behavior:
>
> https://issues.apache.org/jira/browse/VELOCITY-683
>
> https://issues.apache.org/jira/browse/VELOCITY-684
>
> https://issues.apache.org/jira/browse/VELOCITY-752
>
> There also is a great wiki page on the subject:
>
> https://wiki.apache.org/velocity/MacroEvaluationStrategy
>
> As for space gobbling, the correct behavior is probably to have a
> configuration parameter (something like 'velocimacro.evolution.strategy',
> which would take values like 'macro', 'relaxed' for the current behavior,
> and 'sharing'). Also, we ought to avoid making a difference between string
> literals and other literals.
>
> But I'd appreciate to hear your thoughts on the subject. Especially:
>
>  - how should the local scope, if present, affect the sharing mode?
>
>  - how should the macro mode behave if one tries to assign a value to an
> lvalue?
>
>
>   Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: svn commit: r1758416 [1/3] - in /velocity/engine/trunk/velocity-engine-core/src: main/java/org/apache/velocity/runtime/ main/java/org/apache/velocity/runtime/parser/node/ main/java/org/apache/velo

[Nathan Bubna]

Seriously unbelievable. Did i say i'd buy you a drink should you ever come
to town? Well, also, https://cdn.meme.am/instances/500x/53443254.jpg

Of course, Mike, the window isn't closed. Until 2.0 releases, there's still
time! We could argue about the default! Or if there's missing options! Or
anything else that no one (except Claude) will actually invest time into!

On Tue, Aug 30, 2016 at 9:28 AM, Mike Kienenberger 
wrote:

> What?  You would dare to impose your view of configurable whitespace
> gobbling upon the rest of us after only a mere decade of discussion?
>
> What will we talk about for the next 10 years? :-)
>
> On Tue, Aug 30, 2016 at 12:18 PM,   wrote:
> > Author: cbrisson
> > Date: Tue Aug 30 16:18:33 2016
> > New Revision: 1758416
> >
> > URL: http://svn.apache.org/viewvc?rev=1758416=rev
> > Log:
> > [engine] Add a configurable space gobbling feature, to control
> indentation in the generated code.
> >
> > Possible values for the 'space.gobbling' configuration key:
> >
> >  - none : no space gobbling at all
> >  - bc : Velocity 1.x backward compatible space gobbling
> >  - lines (the default) : gobbles whitespaces and endline from lines
> containing a single VTL directive
> >  - structured (beta stage) : like 'lines', but also fixes indentation in
> embedded text blocks
> >
> > The commit also includes some lookahead optimizations and cleaning in
> the javacc parser code.
> >
> >
> > Added:
> > velocity/engine/trunk/velocity-engine-core/src/main/
> java/org/apache/velocity/runtime/parser/node/IndentationFixer.java
> > velocity/engine/trunk/velocity-engine-core/src/test/
> java/org/apache/velocity/test/SpaceGobblingTestCase.java
> >   - copied, changed from r1754151, velocity/engine/trunk/
> velocity-engine-core/src/test/java/org/apache/velocity/test/
> util/introspection/ConversionHandlerTestCase.java
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_smart.vtl.BC
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_smart.vtl.NONE
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_smart.vtl.SMART
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_smart.vtl.STRUCTURED
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_structured.vtl.BC
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_structured.vtl.NONE
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_structured.vtl.SMART
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/foreach_structured.vtl.STRUCTURED
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/if.vtl.BC
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/if.vtl.NONE
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/if.vtl.SMART
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/if.vtl.STRUCTURED
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/macro.vtl.BC
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/macro.vtl.NONE
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/macro.vtl.SMART
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/macro.vtl.STRUCTURED
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/set.vtl.BC
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/set.vtl.NONE
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/set.vtl.SMART
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/set.vtl.STRUCTURED
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/structured.vtl.BC
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/structured.vtl.NONE
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/structured.vtl.SMART
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/compare/structured.vtl.STRUCTURED
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/foreach_smart.vtl
> > velocity/engine/trunk/velocity-engine-core/src/test/
> resources/gobbling/foreach_structured.vtl
> > velocity/engine/trunk/velocity-engine-core/src/test/
> 

Re: ExtendedProperties

[Nathan Bubna]

+1

On Sun, Jul 17, 2016 at 2:50 AM, Will Glass-Husain 
wrote:

> I'm fine with cloning it. Why bring in all the other stuff when we just
> need a simple feature.
>
> On Jul 17, 2016 11:27 AM, "Claude Brisson"  wrote:
>
> > Another reenginering point I'd like to share with you:
> >
> > We're currently quite extensively using
> > org.apache.commons.collections.ExtendedProperties. The main extra feature
> > vs. java.util.Properties is the handling of multi-values keys.
> >
> > We removed the runtime-dependency towards commons-collections by using
> > shading (aka integrating ExtendedProperties class file in our jar).
> >
> > So far, so good.
> >
> > But commons-collections 4.0 removed ExtendedProperties, replaced by
> > org.apache.commons.configuration.PropertiesConfiguration.
> >
> > Either way, I think we can keep the compile-time dependancy towards
> > commons-collections-3 for B.C. The class collections.ExtendedProperties
> > will still be there, shaded, but only used by deprecated methods/classes.
> >
> > We shouldn't keep non-deprecated dependencies towards
> > commons-collections-3, and the dilemma is about the replacement of
> > ExtendedProperties in the new methods and classes. Two options here:
> >
> > 1) use a shaded dependency towards
> > commons.configuration.PropertiesConfiguration
> > 2) host a clone of ExtendedProperties, as
> > org.apache.velocity.utils.ExtProperties
> >
> > Seen from a place far off, option 1 looks like the most natural, but:
> >  - PropertiesConfiguration adds a whole bunch of features we don't really
> > care about
> >  - PropertiesConfiguration belongs to a whole class hierarchy, whereas
> > ExtendedProperties is completely standalone
> >  - integrating PropertiesConfiguration will need more reenginering
> > (constructors aren't the same) and will potentially raise more
> > backward-compatibility problems
> >  - ExtendedProperties is stable and unlikely to need any future change
> >
> > So I'm strongly inclined to implement option 2.
> >
> > For reference, PropertiesConfiguration javadoc:
> >
> >
> https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/PropertiesConfiguration.html
> >
> >
> >Claude
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> > For additional commands, e-mail: dev-h...@velocity.apache.org
> >
> >
>

Re: resource loader API change

[Nathan Bubna]

Not a bad idea.

On Sat, Jul 16, 2016 at 12:31 PM, Sergiu Dumitriu <sergiu.dumit...@gmail.com
> wrote:

> If more backwards-incompatible changes are going to happen, maybe it's
> best to do what several apache-commons project have done: move
> everything to org.apache.velocity2.
>
> On 07/16/2016 09:11 AM, Nathan Bubna wrote:
> > I like ResourceReader or ResourceProvider, as i get confused when classes
> > have the same name and different packages. :)  But i suppose
> > ResourceLoader2 in all its ugliness solves both Will's confusion and my
> > own. Ha!
> >
> > But in all seriousness, you know i'm a big "them that do the work make
> the
> > call" type of guy. I trust your judgement.
> >
> > On Sat, Jul 16, 2016 at 2:27 AM, Claude Brisson <cla...@renegat.net>
> wrote:
> >
> >> I went on with the "2" suffix, but on the ResourceLoader class, hence a
> >> ResourceLoader2 class.
> >>
> >>   Claude
> >>
> >>
> >> On 16/07/2016 10:54, Will Glass-Husain wrote:
> >>
> >>> Makes sense to me.
> >>>
> >>> I'm always confused when names are a little similar but not identical.
> Can
> >>> we just make a package called velocity2 or util2?  Then keep the name
> the
> >>> same ResourceLoader.  It's a little more awkward sounding but is
> actually
> >>> more understandable.
> >>>
> >>> Will
> >>>
> >>>
> >>>
> >>> On Saturday, July 16, 2016, Claude Brisson <cla...@renegat.net> wrote:
> >>>
> >>> I recently commited a long awaited internal API change, letting
> resource
> >>>> loaders rely on Readers+encoding rather than on InputStreams
> >>>> (commits 1752784 and 1752787).
> >>>>
> >>>> As Nathan commented in VELOCITY-793, "Providing B.C. support would be
> >>>> nice, but is certainly not required nor even expected.". But I've got
> a
> >>>> little issue of conscience about how to handle backward compatibility
> >>>> here.
> >>>>
> >>>> We've got a method to deprecate or suppress:
> >>>>
> >>>> InputStream getResourceStream(String source)
> >>>>
> >>>> and a new method:
> >>>>
> >>>>Reader getResourceReader(String source, String encoding)
> >>>>
> >>>> For now, I handled B.C. by deprecating getResourceStream(), and
> >>>> implementing getResourceReader() to rely on the former one. It will
> serve
> >>>> the purpose of letting existing resource loaders work without any
> >>>> modification.
> >>>>
> >>>> But it has a big defect: someone implementing a new resource loader
> will
> >>>> typically want to just implement all absctract methods, which means he
> >>>> will
> >>>> have to implement getResourceStream(), and won't be asked to implement
> >>>> getResourceReader()...
> >>>>
> >>>> So I think we have to deprecate the ResourceLoader class itself, and
> >>>> create a new ResourceReader class.
> >>>>
> >>>> The new ResourceReader class will lack the getResourceStream() method.
> >>>> The
> >>>> deprecated ResourceLoader class will inherit ResourceReader, leave
> >>>> getResourceStream() abstract, and implement getResourceReader().
> >>>>
> >>>> If you have another proposal to name the ResourceReader class, I'm
> >>>> interested. (ResourceFetcher? ResourceProvider?)
> >>>>
> >>>>
> >>>>Claude
> >>>>
> >>>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: resource loader API change

[Nathan Bubna]

I like ResourceReader or ResourceProvider, as i get confused when classes
have the same name and different packages. :)  But i suppose
ResourceLoader2 in all its ugliness solves both Will's confusion and my
own. Ha!

But in all seriousness, you know i'm a big "them that do the work make the
call" type of guy. I trust your judgement.

On Sat, Jul 16, 2016 at 2:27 AM, Claude Brisson  wrote:

> I went on with the "2" suffix, but on the ResourceLoader class, hence a
> ResourceLoader2 class.
>
>   Claude
>
>
> On 16/07/2016 10:54, Will Glass-Husain wrote:
>
>> Makes sense to me.
>>
>> I'm always confused when names are a little similar but not identical. Can
>> we just make a package called velocity2 or util2?  Then keep the name the
>> same ResourceLoader.  It's a little more awkward sounding but is actually
>> more understandable.
>>
>> Will
>>
>>
>>
>> On Saturday, July 16, 2016, Claude Brisson  wrote:
>>
>> I recently commited a long awaited internal API change, letting resource
>>> loaders rely on Readers+encoding rather than on InputStreams
>>> (commits 1752784 and 1752787).
>>>
>>> As Nathan commented in VELOCITY-793, "Providing B.C. support would be
>>> nice, but is certainly not required nor even expected.". But I've got a
>>> little issue of conscience about how to handle backward compatibility
>>> here.
>>>
>>> We've got a method to deprecate or suppress:
>>>
>>> InputStream getResourceStream(String source)
>>>
>>> and a new method:
>>>
>>>Reader getResourceReader(String source, String encoding)
>>>
>>> For now, I handled B.C. by deprecating getResourceStream(), and
>>> implementing getResourceReader() to rely on the former one. It will serve
>>> the purpose of letting existing resource loaders work without any
>>> modification.
>>>
>>> But it has a big defect: someone implementing a new resource loader will
>>> typically want to just implement all absctract methods, which means he
>>> will
>>> have to implement getResourceStream(), and won't be asked to implement
>>> getResourceReader()...
>>>
>>> So I think we have to deprecate the ResourceLoader class itself, and
>>> create a new ResourceReader class.
>>>
>>> The new ResourceReader class will lack the getResourceStream() method.
>>> The
>>> deprecated ResourceLoader class will inherit ResourceReader, leave
>>> getResourceStream() abstract, and implement getResourceReader().
>>>
>>> If you have another proposal to name the ResourceReader class, I'm
>>> interested. (ResourceFetcher? ResourceProvider?)
>>>
>>>
>>>Claude
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

[jira] [Commented] (VELOCITY-553) Posibility to configure ReportInvalidReferences to don't report report variables,properties and method which exist, but only have null value

[Nathan Bubna (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376888#comment-15376888
 ] 

Nathan Bubna commented on VELOCITY-553:
---

Yes, that one i'm sure about. Strict mode should act more like strict typing 
and never be generous about invalid refs, only null ones.

> Posibility to configure ReportInvalidReferences to don't report report 
> variables,properties and method which exist, but only have null value
> 
>
> Key: VELOCITY-553
> URL: https://issues.apache.org/jira/browse/VELOCITY-553
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.5
> Environment: any
>Reporter: Tomáš Procházka
> Fix For: 2.x
>
> Attachments: InvalidEventHandlerTestCase.java.patch
>
>
> ReportInvalidReferences has very big imperfection, it report by default all 
> variables, properties and method which has null value.
> This may cause many problems for developer.
> I for example need only validate template without any data, only check which 
> contain right variables, properties or method (which exist), it's value is 
> not important for me.
> I tried use my own ReferenceInsertionEventHandler for replace null value with 
> "" (empty String) but Velocity call InvalidReference handler before 
> ReferenceInsertionEventHandler.
> I suggest configuration options for this (repor or doesn't report null value)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELOCITY-553) Posibility to configure ReportInvalidReferences to don't report report variables,properties and method which exist, but only have null value

[Nathan Bubna (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376262#comment-15376262
 ] 

Nathan Bubna commented on VELOCITY-553:
---

Good question. My instinct is to say yes, silent is silent and give that 
control to the template instead of letting the configuration override it. But i 
can see arguments either way.

> Posibility to configure ReportInvalidReferences to don't report report 
> variables,properties and method which exist, but only have null value
> 
>
> Key: VELOCITY-553
> URL: https://issues.apache.org/jira/browse/VELOCITY-553
> Project: Velocity
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: 1.5
> Environment: any
>Reporter: Tomáš Procházka
> Fix For: 2.x
>
> Attachments: InvalidEventHandlerTestCase.java.patch
>
>
> ReportInvalidReferences has very big imperfection, it report by default all 
> variables, properties and method which has null value.
> This may cause many problems for developer.
> I for example need only validate template without any data, only check which 
> contain right variables, properties or method (which exist), it's value is 
> not important for me.
> I tried use my own ReferenceInsertionEventHandler for replace null value with 
> "" (empty String) but Velocity call InvalidReference handler before 
> ReferenceInsertionEventHandler.
> I suggest configuration options for this (repor or doesn't report null value)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [VOTE] New site layout - Apache CMS

[Nathan Bubna]

+1 You're my hero, Claude.

On Mon, May 16, 2016 at 4:19 PM, Claude Brisson  wrote:

> Hi Folks.
>
> The site hasn't moved for years, and nobody really knows how to build it
> (it used patched Maven plugins that were once installed somewhere on a
> machine that has since disappeared).
>
> Should we want to release something today, we're more or less stuck. Plus,
> the design is now really outdated, there are plenty of dead links, etc...
>
> So I felt it was time to do something about it, and I had a few days this
> week : the opportinuty makes the thief, I revamped the site layout and
> moved its sources from xdoc/apt/doap/... to markdown and xslt (and a few
> lines of perl).
>
> The site sources are visible here:
> https://svn.apache.org/repos/asf/velocity/site/cms/trunk/
>
> There is a preview here: http://test.renegat.net
>
> I made several choices in the revamping process. I'll try to lighten a bit
> the menus, moved Anakia, DVSL, Texen and DocBook Framework to an Archive
> section, got rid of most of useless empty report pages but tried to keep
> most essential ones. If you feel something is missing, just tell me.
>
> Now to the vote: switch to this new site and to the Apache CMS?
>
> [  ] -1
> [  ] 0
> [  ]+1
>
> Should the vote pass, I'll open an infra issue to switch to the Apache CMS.
>
> Once done, every commiter will be able to update pages on the site by use
> of a simple bookmarklet (which will commit changes, let one preview the
> staged result, then push changes to the production site). Other users can
> use the bookmarklet to submit patches.
>
>
>   --
>   Claude
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: site upgrade...

[Nathan Bubna]

Sounds good to me.

I can't really help much though. The sad reality is that while i still have
a great big soft spot for Velocity, and i'm willing to chime in here and
there, i don't have the time to do any notable work. My employer no longer
uses server-side templating at all, so i can't hack Velocity on work time,
and my personal time is happily devoted to my four kids. I used to have
time for Velocity both at work and home, now, not so much.

On Mon, May 9, 2016 at 11:11 AM, Claude Brisson  wrote:

> Should we publish the 2.0 in less than ten years, it'd be great to upgrade
> not only the site content, but also its design (quite outdated) and
> building tool (ditto). Many apache projects are migrating towards the ASF
> CMS [1], and why not follow the flow?
>
>   Claude
>
> [1] http://www.apache.org/dev/project-site.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: svn commit: r1696822 - in /velocity/tools/trunk: src/site/xdoc/ velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/ velocity-tools-view/src/main/java/org/apache/velocity/tools/vi

[Nathan Bubna]

Sounds reasonable to me. Thanks for tackling this, Claude!

On Sun, Aug 30, 2015 at 9:07 AM, Claude Brisson cla...@renegat.net wrote:

 Some remarks after a little investigation.

 1) Using the ServletContext logger doesn't seem to be a widespread
 practice among slf4j folks. There is a slf4j-servletcontext implementation
 on github, but it is not referenced on the official slf4j site. Moreover, I
 tested it, and it does not support deserialization (I had some doubts about
 it, because deserialization may happen before ServletContext
 initialization), so it cannot be used as is. Plus, it needs to be declared
 as context's listener in the deployment file.

 It's possible to solve those two problems (alas not from our own codebase):
  - The logger object can be a proxy to a transcient implementation that
 waits for the servlet context to be initialized.
  - Since J2EE API v3.0, there is no need to declare the listener in the
 deployment descriptor, as it can be done using Java annotations, which
 would fit slf4j 'jar'-only binding strategy far more than the current state
 of the project.

 But not using the ServletContext logger is not necessarily a bad idea. Of
 course, it's here, so why not use it, but:
  - In practice, container logger and webapp logger serve rather different
 purposes, as container logs won't be active but at initialization or
 destruction.
  - They're not formatted the same way.
  - It's not so cumbersome to watch several log files at once (I mean, on a
 real O.S. with a proper command line, of course) when you need to see both
 at the same time.
  - It's much easier to configure a per-webapp logging (and consequently to
 ease webapp deployment).
  - Gathering logs is always doable at the container level, which can also
 use slf4j (or one of its many bridges), bypassing ServletContext (which is
 just a proxy).

 Anyhow, even it's a little drawback for some people, it can not weight as
 much in the balance as being freed of all logging

 2) We can -and should- keep our logger injection mechanism, since it not
 only helps separating different instances logs, but also permits unifying
 log line prefixes. No more need to define the logger in
 velocity.properties, by default it will be a static logger named
 Velocity. The only constraint when trying to separate instances logs is
 to explicitly give different names to each logger (since the underlying
 LoggerFactory mechanism remains static). Not a big deal.

 Without any other objection, I'll start this drastic simplification very
 soon. We don't even need to keep the o.a.v.runtime.log package. And four
 sub-modules can disappear...

   Claude


 On 21/08/2015 17:25, Nathan Bubna wrote:

 I like simple. :)

 On Fri, Aug 21, 2015 at 2:18 AM, Claude Brissoncla...@renegat.net
 wrote:

 It looks like that with slf4j, we could keep loggers injection even in
 session tools, so no need to go static:

 As of SLF4J version 1.5.3, logger instances survive serialization. Thus,
 serialization of the host class no longer requires any special action,
 even
 when loggers are declared as instance variables. In previous versions,
 logger instances needed to be declared as transient in the host class.
 (http://www.slf4j.org/faq.html#declared_static  )


 So it looks like the perfect solution, and will simplify many things.

Claude



 On 20/08/2015 21:32, Sergiu Dumitriu wrote:

 A recent discussion was proposing to switch to slf4j as the façade.
 On Aug 20, 2015 3:12 PM, Claude Brissoncla...@renegat.net  wrote:

 Thanks for the review.

 Yes, we should be using Velocity logging facade, but I just don't see
 for
 now how we should do this while preserving tools serialization.

 For now I just mimicked a behavior present in some deprecated classes,
 re-introducing the dependency of velocity-tools-view on
 commons-logging.

 I agree that we should try to do better, but if a logger cannot be
 statically reached from a session tool, and if it cannot be passed at
 initialization because of serialization, there's a problem...

 Let say for instance that we use transient weak references on
 non-serializable Velocity loggers, fed up at initialization time. Then
 the
 tool could detect it has lost its logger at deserialization, and ask a
 new
 one, but to whom? It's a bad idea either to keep a static reference on
 the
 servlet context.

 I'm open to suggestions...


 Claude


 On 20/08/2015 20:45, Sergiu Dumitriu wrote:

 Isn't the logging framework supposed to be pluggable, meaning that all

 calls go through org.apache.velocity.runtime.log.Log which is then
 passed to the actual logging library in use, be it log4j, slf4j, jcl
 or
 commons-logging?

 On 08/20/2015 01:16 PM,cbris...@apache.org  wrote:

 Author: cbrisson

 Date: Thu Aug 20 17:16:02 2015
 New Revision: 1696822

 URL:http://svn.apache.org/r1696822
 Log:
 J2EE containers session serialization implies static logging from
 session scoped tools

 Modified:
velocity/tools/trunk/src/site/xdoc

Re: svn commit: r1696822 - in /velocity/tools/trunk: src/site/xdoc/ velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/ velocity-tools-view/src/main/java/org/apache/velocity/tools/vi

[Nathan Bubna]

I like simple. :)

On Fri, Aug 21, 2015 at 2:18 AM, Claude Brisson cla...@renegat.net wrote:

 It looks like that with slf4j, we could keep loggers injection even in
 session tools, so no need to go static:

 As of SLF4J version 1.5.3, logger instances survive serialization. Thus,
 serialization of the host class no longer requires any special action, even
 when loggers are declared as instance variables. In previous versions,
 logger instances needed to be declared as transient in the host class.
 ( http://www.slf4j.org/faq.html#declared_static )

 So it looks like the perfect solution, and will simplify many things.

   Claude



 On 20/08/2015 21:32, Sergiu Dumitriu wrote:

 A recent discussion was proposing to switch to slf4j as the façade.
 On Aug 20, 2015 3:12 PM, Claude Brisson cla...@renegat.net wrote:

 Thanks for the review.

 Yes, we should be using Velocity logging facade, but I just don't see for
 now how we should do this while preserving tools serialization.

 For now I just mimicked a behavior present in some deprecated classes,
 re-introducing the dependency of velocity-tools-view on commons-logging.

 I agree that we should try to do better, but if a logger cannot be
 statically reached from a session tool, and if it cannot be passed at
 initialization because of serialization, there's a problem...

 Let say for instance that we use transient weak references on
 non-serializable Velocity loggers, fed up at initialization time. Then
 the
 tool could detect it has lost its logger at deserialization, and ask a
 new
 one, but to whom? It's a bad idea either to keep a static reference on
 the
 servlet context.

 I'm open to suggestions...


Claude


 On 20/08/2015 20:45, Sergiu Dumitriu wrote:

 Isn't the logging framework supposed to be pluggable, meaning that all
 calls go through org.apache.velocity.runtime.log.Log which is then
 passed to the actual logging library in use, be it log4j, slf4j, jcl or
 commons-logging?

 On 08/20/2015 01:16 PM, cbris...@apache.org wrote:

 Author: cbrisson
 Date: Thu Aug 20 17:16:02 2015
 New Revision: 1696822

 URL: http://svn.apache.org/r1696822
 Log:
 J2EE containers session serialization implies static logging from
 session scoped tools

 Modified:
   velocity/tools/trunk/src/site/xdoc/changes.xml


 velocity/tools/trunk/velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/TilesTool.java


 velocity/tools/trunk/velocity-tools-view/src/main/java/org/apache/velocity/tools/view/AbstractSearchTool.java


 velocity/tools/trunk/velocity-tools-view/src/main/java/org/apache/velocity/tools/view/BrowserTool.java


 velocity/tools/trunk/velocity-tools-view/src/main/java/org/apache/velocity/tools/view/ImportSupport.java


 velocity/tools/trunk/velocity-tools-view/src/main/java/org/apache/velocity/tools/view/tools/ImportTool.java

 Modified: velocity/tools/trunk/src/site/xdoc/changes.xml
 URL:

 http://svn.apache.org/viewvc/velocity/tools/trunk/src/site/xdoc/changes.xml?rev=1696822r1=1696821r2=1696822view=diff


 ==
 --- velocity/tools/trunk/src/site/xdoc/changes.xml (original)
 +++ velocity/tools/trunk/src/site/xdoc/changes.xml Thu Aug 20 17:16:02
 2015
 @@ -35,6 +35,7 @@
liReflect Velocity Engine dependency shading of
 commons-lang
 and commons-collections (cb)/li
liRemoved deprecated class
 org.apache.velocity.tools.generic.log.LogSystemCommonsLog (cb)/li
liMathTool: fixed result type calculations and added
 bitwise
 operations (cb)/li
 +lihave session scoped tools use a static logger to fix J2EE
 containers session serialization (cb)/li
/ul
/subsection

 Modified:

 velocity/tools/trunk/velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/TilesTool.java
 URL:

 http://svn.apache.org/viewvc/velocity/tools/trunk/velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/TilesTool.java?rev=1696822r1=1696821r2=1696822view=diff


 ==
 ---

 velocity/tools/trunk/velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/TilesTool.java
 (original)
 +++

 velocity/tools/trunk/velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/TilesTool.java
 Thu Aug 20 17:16:02 2015
 @@ -101,7 +101,6 @@ public class TilesTool extends ImportSup
setRequest(ctx.getRequest());
setResponse(ctx.getResponse());
setServletContext(ctx.getServletContext());
 -setLog(ctx.getVelocityEngine().getLog());
}
}

 Modified:

 velocity/tools/trunk/velocity-tools-view/src/main/java/org/apache/velocity/tools/view/AbstractSearchTool.java
 URL:

 http://svn.apache.org/viewvc/velocity/tools/trunk/velocity-tools-view/src/main/java/org/apache/velocity/tools/view/AbstractSearchTool.java?rev=1696822r1=1696821r2=1696822view=diff


 

Re: Need to be added to the VELTOOLS jira admin role

[Nathan Bubna]

Not sure anyone still uses Anakia, but ok. :)

On Thu, Jun 11, 2015 at 4:54 PM, Mike Kienenberger mkien...@gmail.com
wrote:

 There's a few more DOAP files I need to fix.I grabbed the issue
 for VELOCITY.

 So that just leaves ANAKIA-7 -- can you add me as a jira admin for
 that project as well?



 On Thu, Jun 11, 2015 at 7:33 PM, Nathan Bubna nbu...@gmail.com wrote:
  Done. Thanks :)
 
  On Thu, Jun 11, 2015 at 4:25 PM, Mike Kienenberger mkien...@gmail.com
  wrote:
 
  I need to be added to the VELTOOLS jira admin role (mkienenb).I'll
  probably end up doing work on veltools at some point in any case as
  it's the other thing I use in addition to engine.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Need to be added to the VELTOOLS jira admin role

[Nathan Bubna]

I think i got them all. Tell me if i missed one. :)

On Thu, Jun 11, 2015 at 5:13 PM, Sergiu Dumitriu sergiu.dumit...@gmail.com
wrote:

 Same here, and also other Velocity projects:

 ANAKIA
 DBF
 DVSL
 TEXEN
 VELOCITY
 VELOCITYSB
 VELTOOLS

 Taken from:
 https://issues.apache.org/jira/secure/BrowseProjects.jspa#10200

 On 06/11/2015 07:25 PM, Mike Kienenberger wrote:
  I need to be added to the VELTOOLS jira admin role (mkienenb).I'll
  probably end up doing work on veltools at some point in any case as
  it's the other thing I use in addition to engine.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 


 --
 Sergiu Dumitriu
 http://purl.org/net/sergiu/

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Need to be added to the VELTOOLS jira admin role

[Nathan Bubna]

You and Sergiu and the velocity-developers should all have JIRA admin privs
for all Velocity sub-projects now (Anakia, Texen, DVSL, Docbook Framework,
etc), assuming i did that right. :)


On Thu, Jun 11, 2015 at 5:05 PM, Mike Kienenberger mkien...@gmail.com
wrote:

 It's more of a matter of the global DOAP scripts being messed up due
 to bad data in our file.   I don't remember all the details, but sebb
 is making a big push to fix everything.

 On Thu, Jun 11, 2015 at 8:04 PM, Nathan Bubna nbu...@gmail.com wrote:
  Not sure anyone still uses Anakia, but ok. :)
 
  On Thu, Jun 11, 2015 at 4:54 PM, Mike Kienenberger mkien...@gmail.com
  wrote:
 
  There's a few more DOAP files I need to fix.I grabbed the issue
  for VELOCITY.
 
  So that just leaves ANAKIA-7 -- can you add me as a jira admin for
  that project as well?
 
 
 
  On Thu, Jun 11, 2015 at 7:33 PM, Nathan Bubna nbu...@gmail.com wrote:
   Done. Thanks :)
  
   On Thu, Jun 11, 2015 at 4:25 PM, Mike Kienenberger 
 mkien...@gmail.com
   wrote:
  
   I need to be added to the VELTOOLS jira admin role (mkienenb).
 I'll
   probably end up doing work on veltools at some point in any case as
   it's the other thing I use in addition to engine.
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
   For additional commands, e-mail: dev-h...@velocity.apache.org
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: general@velocity mailing list

[Nathan Bubna]

Sounds great, thanks!

On Tue, Jun 9, 2015 at 7:17 AM, Mike Kienenberger mkien...@gmail.com
wrote:

 Well, it's been 10 days, so I'll assume lazy consensus for the rest of
 the velocity team.


 Our first step is to remove the mailing list information from our web
 site.  This is a good excuse to figure out how the web site is
 generated and published, so I'll take a look at this one, as I
 understand at least the second part.


 Our second step is send out a message and shut down the general@ list.

 How does this sound?

 
 Subject: Discontinuing general@velocity mailing list. Switch to
 user@velocity.

 Velocity community members:

 We are shutting down the gene...@velocity.apache.org mailing list as
 it duplicates the u...@velocity.apache.org mailing list and is not
 publicly mirrored elsewhere, unlike our other mailing lists on
 nabble.com or mail-archive.org.

 If you no longer wish to receive velocity-related information, or you
 are already subscribed to the u...@velocity.apache.org mailing list,
 no further action is required.

 If you are subscribed to gene...@velocity.apache.org but not
 subscribed to u...@velocity.apache.org, and you wish to continue to
 receive velocity-related messages, you will need to subscribe to
 u...@velocity.apache.org by sending an email to
 user-subscr...@velocity.apache.org to sign up (no subject or message
 body required) as described here:

http://velocity.apache.org/engine/devel/mail-lists.html

 Best regards,
 The Apache Velocity development team

 


 Our third and final step will be to open an INFRA ticket and ask that
 the general@ mailing list be removed.


 On Sat, May 30, 2015 at 12:29 PM, Nathan Bubna nbu...@gmail.com wrote:
  +1
 
  On Sat, May 30, 2015 at 7:58 AM, Frederick N. Brier fnbr...@gmail.com
  wrote:
 
  Sounds good to me :).
 
 
  On 05/30/2015 04:11 AM, Mike Kienenberger wrote:
 
  And while we're at it, why have a general@apache mailing list?
  Something inherited from Jakarta?   It's not archived or publicly
  visible on nabble or mail-archive.com.   Users have a difficult enough
  time determining whether a posting should go to user@ and dev@.   I
  see nothing that differentiates between general@ and user@.
 
  I propose we remove the mailing list from our mailing lists page, and
  post a last message to general@ that we're shutting down general@ and
  switching existing subscribers to user@, and include instructions on
  how to unsubscribe from user@.  That's if we want to go opt-out.   Or
  go with opt-in, and post a last message to general@ that we're
  shutting down general@ and include instructions on how to subscribe to
  user@.   Opt-in is probably the better approach.  Then we ask infra to
  shut down the mailing list and optionally set up a redirect from
  general@ to user@.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: 1.8-SNAPSHOT as version for 1.x pom.xml?

[Nathan Bubna]

When it's more work to open the issue than fix it, just fix it. :)

On Tue, Jun 2, 2015 at 7:57 PM, Mike Kienenberger mkien...@gmail.com
wrote:

 Do you think we need to open issues for trivial obviously-broken build
 issues like this?

 I'm going to guess no.

 On Tue, Jun 2, 2015 at 10:56 PM, Sergiu Dumitriu
 sergiu.dumit...@gmail.com wrote:
  1.7 is definitely wrong, since a non -SNAPSHOT version should only be
  present in a tagged release. So yes, that needs to be changed.
 
  On 06/02/2015 10:52 PM, Mike Kienenberger wrote:
  My maven knowledge is tragically small.
  Do we need to make the following change for the 1.x pom.xml?
 
  Index: pom.xml
  ===
  --- pom.xml(revision 1683209)
  +++ pom.xml(working copy)
  @@ -33,7 +33,7 @@
 
 groupIdorg.apache.velocity/groupId
 artifactIdvelocity/artifactId
  -  version1.7/version
  +  version1.8-SNAPSHOT/version
 
 nameApache Velocity/name
 urlhttp://velocity.apache.org/engine/devel//url
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 
 
 
  --
  Sergiu Dumitriu
  http://purl.org/net/sergiu/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Fixing build issues in 1.x but not 2.x

[Nathan Bubna]

VELOCITY-862 would probably still apply to the 2.x branch, i suspect.

Moving on with 1.8 sounds sensible to me.

On Tue, Jun 2, 2015 at 7:46 PM, Mike Kienenberger mkien...@gmail.com
wrote:

 I hope it's not a problem, but I'm only applying the build process
 fixes to the 1.x branch and not the 2.x branch.

 My thinking is that the work has most likely already been done on 2.x,
 and I'm also not sure I have the time to invest in the 2.x branch.

 If you see something that you think I should also apply to 2.x, let me
 know, and I'll try to find time to make it happen -- or apply it
 yourself.

 I know we have 1.7.1 as a potential release candidate, but I think we
 should skip it and start with a 1.8 release.   As an end-user, I would
 expect 1.7.1 to be built with the same tools as 1.7, and I doubt any
 of us have java 1.4 installed any longer.

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

[RESULT] [VOTE] Mike Kienenberger as committer

[Nathan Bubna]

Alrighty, voting is closed.

We have 5 binding +1, 2 non-binding +1, and one binding +0.

The vote passes, now i just gotta remember how to grant him svn access and
all that... :)


On Fri, May 29, 2015 at 10:57 AM, Daniel Rall d...@finemaltcoding.com
wrote:

 +0, haven't been tracking.

 On Fri, May 29, 2015 at 8:20 AM Nathan Bubna nbu...@apache.org wrote:

  Hi all,
 
  Mike Kienenberger has been an active part of the Velocity community for
 at
  least a decade, IIRC. He is already a committer and PMC member on various
  ASF projects (http://people.apache.org/committer-index.html#mkienenb).
 And
  now he's begun filing issues and patches.
 
  I figure it's easier to give him commit access than to commit those
 things
  for him. :)
 
  What say ye?
 
  [ ] +1 Sounds good.
  [ ] +/- 0 Not sure, because...
  [ ] -1 No. Because...
 
  My vote is +1
 
  Vote ends in about three days (sometime Monday)
 

Re: svn commit: r1682680 - in /velocity/engine/branches/1.x/build: build.properties download.xml

[Nathan Bubna]

The 1.x branch is the head of 1.x development. Effectively, it's what
could become a 1.8 version.

On Sun, May 31, 2015 at 10:15 AM, Mike Kienenberger mkien...@gmail.com
wrote:

 What's the 1.x branch?

 We should also make sure that the 1.5 patch is applied to the
 Velocity_1.5_BRANCH branch so someone checking out from svn can at
 least build 1.5 from source, although, like 1.6, I doubt we will be
 making another release.

 On Sun, May 31, 2015 at 2:24 AM,  sdumit...@apache.org wrote:
  Author: sdumitriu
  Date: Sun May 31 06:24:10 2015
  New Revision: 1682680
 
  URL: http://svn.apache.org/r1682680
  Log:
  VELOCITY-860: Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency
 build script
  Patch from Mike Kienenberger applied without changes
 
  Modified:
  velocity/engine/branches/1.x/build/build.properties
  velocity/engine/branches/1.x/build/download.xml
 
  Modified: velocity/engine/branches/1.x/build/build.properties
  URL:
 http://svn.apache.org/viewvc/velocity/engine/branches/1.x/build/build.properties?rev=1682680r1=1682679r2=1682680view=diff
 
 ==
  --- velocity/engine/branches/1.x/build/build.properties (original)
  +++ velocity/engine/branches/1.x/build/build.properties Sun May 31
 06:24:10 2015
  @@ -119,8 +119,8 @@ proxy.port= 80
 
   #
   # We download directly from the ibiblio maven repository
  -repo.m1.url= http://www.ibiblio.org/maven
  -repo.m2.url=http://www.ibiblio.org/maven2
  +repo.m1.url= http://mirrors.ibiblio.org/maven2
  +repo.m2.url=http://mirrors.ibiblio.org/maven2
   #
   # Jars to be downloaded
   jar.antlr.version= 2.7.5
 
  Modified: velocity/engine/branches/1.x/build/download.xml
  URL:
 http://svn.apache.org/viewvc/velocity/engine/branches/1.x/build/download.xml?rev=1682680r1=1682679r2=1682680view=diff
 
 ==
  --- velocity/engine/branches/1.x/build/download.xml (original)
  +++ velocity/engine/branches/1.x/build/download.xml Sun May 31 06:24:10
 2015
  @@ -62,7 +62,7 @@
 
 target name=do-http-m1-download unless=skip-download
   setproxy proxyhost=${proxy.host} proxyport=${proxy.port}/
  -get
 src=${repo.m1.url}/${download.groupId}/jars/${download.artifactId}-${download.version}.jar
  +get
 src=${repo.m1.url}/${download.groupId}/${download.artifactId}/${download.version}/${download.artifactId}-${download.version}.jar
 
  dest=${build.lib}/${download.artifactId}-${download.version}.jar
usetimestamp=true
verbose=false
  @@ -84,7 +84,7 @@
 
 target name=do-http-test-m1-download unless=skip-download
   setproxy proxyhost=${proxy.host} proxyport=${proxy.port}/
  -get
 src=${repo.m1.url}/${download.groupId}/jars/${download.artifactId}-${download.version}.jar
  +get
 src=${repo.m1.url}/${download.groupId}/${download.artifactId}/${download.version}/${download.artifactId}-${download.version}.jar
 
  dest=${build.test.lib}/${download.artifactId}-${download.version}.jar
usetimestamp=true
verbose=false
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: svn commit: r1682680 - in /velocity/engine/branches/1.x/build: build.properties download.xml

[Nathan Bubna]

Heh. Pretty sure we don't actually need any new releases (even of the 1.5
branch) to target 1.4. In fact, i don't believe we need or want any new
1.5.x releases.  We've long considered 1.5 to be flawed, with major
performance regressions. Don't waste your time on it. :)

On Sun, May 31, 2015 at 2:43 PM, Sergiu Dumitriu sergiu.dumit...@gmail.com
wrote:

 OK, I applied the patch on the 1.5 branch as well.

 Building that branch still fails.

 With JDK1.7 there's a missing implementation for a new method added in a
 standard interface.

 With JDK1.6 packaging fails since the build script insists on building
 with a 1.4 JDK, and I doubt people still have one of those around.

 On 05/31/2015 01:15 PM, Mike Kienenberger wrote:
  What's the 1.x branch?
 
  We should also make sure that the 1.5 patch is applied to the
  Velocity_1.5_BRANCH branch so someone checking out from svn can at
  least build 1.5 from source, although, like 1.6, I doubt we will be
  making another release.
 
  On Sun, May 31, 2015 at 2:24 AM,  sdumit...@apache.org wrote:
  Author: sdumitriu
  Date: Sun May 31 06:24:10 2015
  New Revision: 1682680
 
  URL: http://svn.apache.org/r1682680
  Log:
  VELOCITY-860: Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency
 build script
  Patch from Mike Kienenberger applied without changes
 
  Modified:
  velocity/engine/branches/1.x/build/build.properties
  velocity/engine/branches/1.x/build/download.xml
 
  Modified: velocity/engine/branches/1.x/build/build.properties
  URL:
 http://svn.apache.org/viewvc/velocity/engine/branches/1.x/build/build.properties?rev=1682680r1=1682679r2=1682680view=diff
 
 ==
  --- velocity/engine/branches/1.x/build/build.properties (original)
  +++ velocity/engine/branches/1.x/build/build.properties Sun May 31
 06:24:10 2015
  @@ -119,8 +119,8 @@ proxy.port= 80
 
   #
   # We download directly from the ibiblio maven repository
  -repo.m1.url= http://www.ibiblio.org/maven
  -repo.m2.url=http://www.ibiblio.org/maven2
  +repo.m1.url= http://mirrors.ibiblio.org/maven2
  +repo.m2.url=http://mirrors.ibiblio.org/maven2
   #
   # Jars to be downloaded
   jar.antlr.version= 2.7.5
 
  Modified: velocity/engine/branches/1.x/build/download.xml
  URL:
 http://svn.apache.org/viewvc/velocity/engine/branches/1.x/build/download.xml?rev=1682680r1=1682679r2=1682680view=diff
 
 ==
  --- velocity/engine/branches/1.x/build/download.xml (original)
  +++ velocity/engine/branches/1.x/build/download.xml Sun May 31 06:24:10
 2015
  @@ -62,7 +62,7 @@
 
 target name=do-http-m1-download unless=skip-download
   setproxy proxyhost=${proxy.host} proxyport=${proxy.port}/
  -get
 src=${repo.m1.url}/${download.groupId}/jars/${download.artifactId}-${download.version}.jar
  +get
 src=${repo.m1.url}/${download.groupId}/${download.artifactId}/${download.version}/${download.artifactId}-${download.version}.jar
 
  dest=${build.lib}/${download.artifactId}-${download.version}.jar
usetimestamp=true
verbose=false
  @@ -84,7 +84,7 @@
 
 target name=do-http-test-m1-download unless=skip-download
   setproxy proxyhost=${proxy.host} proxyport=${proxy.port}/
  -get
 src=${repo.m1.url}/${download.groupId}/jars/${download.artifactId}-${download.version}.jar
  +get
 src=${repo.m1.url}/${download.groupId}/${download.artifactId}/${download.version}/${download.artifactId}-${download.version}.jar
 
  dest=${build.test.lib}/${download.artifactId}-${download.version}.jar
usetimestamp=true
verbose=false
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 


 --
 Sergiu Dumitriu
 http://purl.org/net/sergiu/

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: No JIRA changes sent to a mailing list?

[Nathan Bubna]

Definitely dev@

Thanks, Sergiu!

On Sat, May 30, 2015 at 5:18 AM, Mike Kienenberger mkien...@gmail.com
wrote:

 I'd say dev.   If you want to move discussion from an issue to the
 mailing list, having them sent to dev makes replying easy.

 Plus, people who are subscribed to commits likely only want to see
 actual changes, not potential problems.


 On Sat, May 30, 2015 at 7:57 AM, Sergiu Dumitriu
 sergiu.dumit...@gmail.com wrote:
  I was just about to send a similar mail. The issue is that it's
  configured to send emails to velocity-...@jakarta.apache.org, which I
  believe is not valid anymore. I don't know who can change this, since as
  a project administrator I can't change that. Probably something infra
  must handle (cc-ing).
 
  Infra: for the VELOCITY jira project, the notification scheme must be
  changed to send emails to dev@velocity.apache.org instead of the defunct
  velocity-...@jakarta.apache.org
 
  (or should that be comm...@velocity.apache.org?)
 
  On 05/30/2015 06:54 AM, Mike Kienenberger wrote:
  I signed up for the commits mailing list, but as I was looking through
  the archives, I noticed that there's no JIRA change notifications sent
  to commit@, nor are they sent to dev@.  Shouldn't these be going to a
  mailing list?  How do you subscribe to JIRA changes?
 
  --
  Sergiu Dumitriu
  http://purl.org/net/sergiu/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
  For additional commands, e-mail: dev-h...@velocity.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

Re: general@velocity mailing list

[Nathan Bubna]

+1

On Sat, May 30, 2015 at 7:58 AM, Frederick N. Brier fnbr...@gmail.com
wrote:

 Sounds good to me :).


 On 05/30/2015 04:11 AM, Mike Kienenberger wrote:

 And while we're at it, why have a general@apache mailing list?
 Something inherited from Jakarta?   It's not archived or publicly
 visible on nabble or mail-archive.com.   Users have a difficult enough
 time determining whether a posting should go to user@ and dev@.   I
 see nothing that differentiates between general@ and user@.

 I propose we remove the mailing list from our mailing lists page, and
 post a last message to general@ that we're shutting down general@ and
 switching existing subscribers to user@, and include instructions on
 how to unsubscribe from user@.  That's if we want to go opt-out.   Or
 go with opt-in, and post a last message to general@ that we're
 shutting down general@ and include instructions on how to subscribe to
 user@.   Opt-in is probably the better approach.  Then we ask infra to
 shut down the mailing list and optionally set up a redirect from
 general@ to user@.

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org