[jira] [Commented] (VELOCITY-947) Input macro variable not changed outside scope

[Mike Kienenberger (Jira)]

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

Mike Kienenberger commented on VELOCITY-947:


I'll still do fixes against 1.7.x if someone provides a patch.

> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning 
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x 
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
>   #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside 
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
>  https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>  
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString() 
> method.
> I am attaching a project with the tests. You can change the velocity version 
> in _build.gradle_ and run with _./gradlew run_



--
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-947) Input macro variable not changed outside scope

[Mike Kienenberger (Jira)]

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

Mike Kienenberger commented on VELOCITY-947:


I don't think many people are using the 1.7.x branch (I am) and I'm guessing 
that of those that are, either they are not using local scope for macros or 
they've avoided using the same name in both macros and globally.

 

I'll go ahead and leave this open.   If you want to provide a patch for this 
issue, I'll apply it.

> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning 
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x 
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
>   #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside 
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
>  https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>  
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString() 
> method.
> I am attaching a project with the tests. You can change the velocity version 
> in _build.gradle_ and run with _./gradlew run_



--
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] [Reopened] (VELOCITY-947) Input macro variable not changed outside scope

[Mike Kienenberger (Jira)]

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

Mike Kienenberger reopened VELOCITY-947:


Apparently not a configuration issue.  Re-opening.

> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning 
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x 
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
>   #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside 
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
>  https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>  
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString() 
> method.
> I am attaching a project with the tests. You can change the velocity version 
> in _build.gradle_ and run with _./gradlew run_



--
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-947) Input macro variable not changed outside scope

[Mike Kienenberger (Jira)]

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

Mike Kienenberger edited comment on VELOCITY-947 at 8/6/21, 2:00 PM:
-

I'm pretty sure this is a matter of setting configuration parameters rather 
than a bug.   Let me know if ihat turns out not to be the case, and I'll reset 
the status it as "Won't fix" instead of "Not A Bug"


was (Author: mkienenb):
I'm pretty sure this is a matter of setting configuration parameters rather 
than a bug.   YLet me know if ihat turns out not to be the case, and I'll reset 
the status it as "Won't fix" instead of "Not A Bug"

> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning 
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x 
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
>   #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside 
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
>  https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>  
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString() 
> method.
> I am attaching a project with the tests. You can change the velocity version 
> in _build.gradle_ and run with _./gradlew run_



--
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] [Resolved] (VELOCITY-947) Input macro variable not changed outside scope

[Mike Kienenberger (Jira)]

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

Mike Kienenberger resolved VELOCITY-947.

Resolution: Not A Bug

I'm pretty sure this is a matter of setting configuration parameters rather 
than a bug.   YLet me know if ihat turns out not to be the case, and I'll reset 
the status it as "Won't fix" instead of "Not A Bug"

> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning 
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x 
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
>   #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside 
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
>  https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>  
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString() 
> method.
> I am attaching a project with the tests. You can change the velocity version 
> in _build.gradle_ and run with _./gradlew run_



--
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-947) Input macro variable not changed outside scope

[Mike Kienenberger (Jira)]

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

Mike Kienenberger commented on VELOCITY-947:


Everything you've said is likely true, but the 1.x branch is velocity is no 
longer maintained.

Have you tried using the {{velocimacro.context.localscope}} parameter?
{noformat}
velocimacro.context.localscope

This property has the possible values true or false, and the default is false. 
When true, any modifications to the context via #set() within a Velocimacro are 
considered 'local' to the Velocimacro, and will not permanently affect the 
context.
{noformat}
I do have a note from July 2008 in my config file (where it is set to false) 
that states: "Setting to true broke passing parameters into macros." but this 
project started with velocity 1.3.1, so I can't say which version it applied 
to.other than before 1.6, so this is likely your solution for 1.6.1 through 
1.7.x.

 

Also, there is an unreleased version 1.8 at 
[https://github.com/apache/velocity-engine/tree/1.7.x/src] which you might want 
to use as a step between 1.7 and 2.0.

 

> Input macro variable not changed outside scope
> --
>
> Key: VELOCITY-947
> URL: https://issues.apache.org/jira/browse/VELOCITY-947
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x
>Reporter: Fabio Nascimento Brandão
>Priority: Major
> Attachments: variable_velocity.tar.gz
>
>
> I am migrating an application from Velocity Engine 1.5 to 1.7 (I am planning 
> to migrate to 2.x later) and I found a different behavior between 1.5, 1.6.x 
> and 1.7 versions.
> If you have this template:
> {code:java}
> #macro(testMacro $variable $newValue)
>   #set($variable = $newValue)
> #end
> #set($testevar = 'INCORRECT')
> Var before: $testevar
> #testMacro($testevar 'TEST OK')
> Var after: $testevar
> {code}
> The output for the versions 1.5, 1.6, 1.6.2, 1.6.3 and 1.6.4 are:
> {code:java}
> Var before: INCORRECT
> Var after: TEST OK
> {code}
> And for versions 1.6.1 and 1.7 are:
> {code:java}
> Var before: INCORRECT
> Var after: INCORRECT
> {code}
> In 1.5, the set inside macro was changing the referenced variable outside 
> macro's scope. In 1.6.1 and 1.7 the variable is not changed.
> I think this change was introduced by this issue:
>  https://issues.apache.org/jira/browse/VELOCITY-615
> In this method:
>  
> [https://github.com/apache/velocity-engine/commit/e0dec30ef0107ba0066fa18facdc1f7f2677087c#diff-79959d90eea878dd1d2550fa30aff8653a583339fe8125133b6a23573f2a0848L169-R173]
> Before the change, the context was updated with the key from getRootString() 
> method.
> I am attaching a project with the tests. You can change the velocity version 
> in _build.gradle_ and run with _./gradlew run_



--
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: [OT] Problems with commons-beanutils-1.9.4

[Mike Kienenberger]

I'm still maintaining a project using a Velocity 1.8-snapshot and struts.
If I recall, I think the lack of a path forward for struts was why I did
not upgrade to 2.x.
But I'm also stuck with an ancient version of struts, so my situation may
be unique.

On Sat, Mar 14, 2020 at 9:47 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Claude,
>
> On 2/7/20 02:09, 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?
>
> Yes.
>
> > 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...
>
> That would be nice, but I don't know if there is any appetite over
> there to take-on this project.
>
> I might be able to find time to maintain it myself, but I'd want to
> make sure at least a few other people in that community cared enough
> to keep it going, too.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5s4GIACgkQHPApP6U8
> pFhsmw/9ENxOVTd93a6Mt2353ITH9FVrFWdmGGrPxtL/HKL8CNKoG+Xy1HCoczOW
> vVpkX2aCu4MNllKO6I+zV6OE6k6aKFsnpgbycPHkodL1qmk9U9lNlIoGLhcYRvrV
> ACqn+Yety3J4Tem4gIbPTCmpAtLvyEquJqY11yLDvDdg3De4uVMuyqQAccr9s1v7
> 8+n5QwqShXd+TTmj+bFWaPrig9uuNy7h3R6tmxNdLmqrk2fs4trfFGbHbcUS5lwH
> ycamhSFHl7OHXc2/4M3tAYMt4pV3fKyvBsni0/l1VnXmQyu5o6XqdZHPstGaOAeL
> xRr2x4GtaCItKEr3jo+Gwz8Z8jZhBiCsD1TbbPQBPXcmK71GAXY7+i9XrpwuvMEW
> KRzgijCpXE3IRkcRt9bGTFMRW6SDyTcZkCH9eg+c/m6WTD1tf4FSZGSrpoqIUA/0
> PXyc2gtw3ez0M8qTA3FDiKIu9T7vMLeBC/SoSudjwWwJFgu5POb5bi74PpqIasFe
> xWBoelzd2qcVvgo4F1hctZ2JQdL+jkAzHY5la3DjVE8L5MXX75fUUsJezRhFhCKQ
> 2BtzjeijH48cAFjlJi/1PGsN9TF/aZnGocYlazHIjvAz8sJbRjc2f+FPhRQzNjBW
> sStpMTeQ2NL3KhYh6jX3y99+5Cxf4+Nx23d7RKRi4TNVL/BpmeE=
> =QNg+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

[jira] [Commented] (VELOCITY-816) Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.

[Mike Kienenberger (Jira)]

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

Mike Kienenberger commented on VELOCITY-816:


Sorry – It's been so long that I can't remember what it was that I was supposed 
to be doing

 

> Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.
> --
>
> Key: VELOCITY-816
> URL: https://issues.apache.org/jira/browse/VELOCITY-816
> Project: Velocity
>  Issue Type: Improvement
>Reporter: Craig P. Motlin
>Assignee: Claude Brisson
>Priority: Major
>




--
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] [Closed] (VELOCITY-899) Update build process for Java 1.8 and new dependency locations

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger closed VELOCITY-899.
--
   Resolution: Fixed
Fix Version/s: 1.7.x

Fixed on 1.7.x branch.

> Update build process for Java 1.8 and new dependency locations
> --
>
> Key: VELOCITY-899
> URL: https://issues.apache.org/jira/browse/VELOCITY-899
> Project: Velocity
>  Issue Type: Improvement
>  Components: Build, Engine
>Affects Versions: 1.7.x
>    Reporter: Mike Kienenberger
>    Assignee: Mike Kienenberger
>Priority: Major
> Fix For: 1.7.x
>
>
> - Update Velocity version to 1.7.1.
>  - Update required java version to 1.8.
>  - Update javadocs location.
>  - Change dependency jar location URL from "mirrors" to "maven".
>  - Add hsqldb DataSource getParentLogger() API method.
>  - Backport fix to exclude VelTools66TestCase.java when using java 1.8 or 
> greater.



--
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] [Closed] (VELOCITY-882) Critical vulnerability in commons collection

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger closed VELOCITY-882.
--
Resolution: Fixed

Fixed on 1.7.x branch.

> Critical vulnerability in commons collection
> 
>
> Key: VELOCITY-882
> URL: https://issues.apache.org/jira/browse/VELOCITY-882
> Project: Velocity
>  Issue Type: Bug
>Reporter: Emile Fugulin
>Assignee: Mike Kienenberger
>Priority: Major
> Fix For: 1.7.x, 2.0
>
>
> Hi, 
> Snyk reported to us that velocity 1.7 contains a dependency to 
> commons-collection 3.2.1 which is vulnerable to arbitrary code execution.
> https://snyk.io/vuln/SNYK-JAVA-COMMONSCOLLECTIONS-30078
> This should be fixed since many lib depends on this library...



--
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] [Updated] (VELOCITY-882) Critical vulnerability in commons collection

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-882:
---
Fix Version/s: 2.0
   1.7.x

> Critical vulnerability in commons collection
> 
>
> Key: VELOCITY-882
> URL: https://issues.apache.org/jira/browse/VELOCITY-882
> Project: Velocity
>  Issue Type: Bug
>Reporter: Emile Fugulin
>Assignee: Mike Kienenberger
>Priority: Major
> Fix For: 1.7.x, 2.0
>
>
> Hi, 
> Snyk reported to us that velocity 1.7 contains a dependency to 
> commons-collection 3.2.1 which is vulnerable to arbitrary code execution.
> https://snyk.io/vuln/SNYK-JAVA-COMMONSCOLLECTIONS-30078
> This should be fixed since many lib depends on this library...



--
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] [Reopened] (VELOCITY-882) Critical vulnerability in commons collection

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reopened VELOCITY-882:

  Assignee: Mike Kienenberger

It's a simple fix for branch 1.7.x so I'll go ahead and apply it.

> Critical vulnerability in commons collection
> 
>
> Key: VELOCITY-882
> URL: https://issues.apache.org/jira/browse/VELOCITY-882
> Project: Velocity
>  Issue Type: Bug
>Reporter: Emile Fugulin
>Assignee: Mike Kienenberger
>Priority: Major
>
> Hi, 
> Snyk reported to us that velocity 1.7 contains a dependency to 
> commons-collection 3.2.1 which is vulnerable to arbitrary code execution.
> https://snyk.io/vuln/SNYK-JAVA-COMMONSCOLLECTIONS-30078
> This should be fixed since many lib depends on this library...



--
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] [Updated] (VELOCITY-899) Update build process for Java 1.8 and new dependency locations

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-899:
---
Description: 
- Update Velocity version to 1.7.1.
 - Update required java version to 1.8.
 - Update javadocs location.
 - Change dependency jar location URL from "mirrors" to "maven".
 - Add hsqldb DataSource getParentLogger() API method.
 - Backport fix to exclude VelTools66TestCase.java when using java 1.8 or 
greater.

  was:
- Dependency location in maven has changed again.

 


> Update build process for Java 1.8 and new dependency locations
> --
>
> Key: VELOCITY-899
> URL: https://issues.apache.org/jira/browse/VELOCITY-899
> Project: Velocity
>  Issue Type: Improvement
>  Components: Build, Engine
>Affects Versions: 1.7.x
>Reporter: Mike Kienenberger
>Assignee: Mike Kienenberger
>Priority: Major
>
> - Update Velocity version to 1.7.1.
>  - Update required java version to 1.8.
>  - Update javadocs location.
>  - Change dependency jar location URL from "mirrors" to "maven".
>  - Add hsqldb DataSource getParentLogger() API method.
>  - Backport fix to exclude VelTools66TestCase.java when using java 1.8 or 
> greater.



--
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] [Updated] (VELOCITY-899) Update build process for Java 1.8 and new dependency locations

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-899:
---
Description: 
- Dependency location in maven has changed again.

 

  was:
Dependency location in maven has changed again.

 


> Update build process for Java 1.8 and new dependency locations
> --
>
> Key: VELOCITY-899
> URL: https://issues.apache.org/jira/browse/VELOCITY-899
> Project: Velocity
>  Issue Type: Improvement
>  Components: Build, Engine
>Affects Versions: 1.7.x
>    Reporter: Mike Kienenberger
>    Assignee: Mike Kienenberger
>Priority: Major
>
> - Dependency location in maven has changed again.
>  



--
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] [Updated] (VELOCITY-899) Update build process for Java 1.8 and new dependency locations

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-899:
---
Description: 
Dependency location in maven has changed again.

 

> Update build process for Java 1.8 and new dependency locations
> --
>
> Key: VELOCITY-899
> URL: https://issues.apache.org/jira/browse/VELOCITY-899
> Project: Velocity
>  Issue Type: Improvement
>  Components: Build, Engine
>Affects Versions: 1.7.x
>    Reporter: Mike Kienenberger
>    Assignee: Mike Kienenberger
>Priority: Major
>
> Dependency location in maven has changed again.
>  



--
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] [Created] (VELOCITY-899) Update build process for Java 1.8 and new dependency locations

[Mike Kienenberger (JIRA)]

Mike Kienenberger created VELOCITY-899:
--

 Summary: Update build process for Java 1.8 and new dependency 
locations
 Key: VELOCITY-899
 URL: https://issues.apache.org/jira/browse/VELOCITY-899
 Project: Velocity
  Issue Type: Improvement
  Components: Build, Engine
Affects Versions: 1.7.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger






--
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: Problem in Eclipse with JBoss's java2ws using velocity - "The specified logger class org.apache.velocity.runtime.log.NullLogSystem does not implement the org.apache.velocity.runtime.log.LogChute i

[Mike Kienenberger]

While I can't share the code, one of my clients has written a generic
class that dumps the current app's classpath, so this can be done
within your own java code.

The code I have access to is much more complicated, but a simple
approach can be found here:

http://www.mkyong.com/java/how-to-print-out-the-current-project-classpath/

The approached used by my client checked the "java.class.path" system
property, pulled out the classes in the JRE's lib/rt.jar file for
bootstrap classes, as well as the JRE's lib/ext classes.
It then pulled out the actual classes used with specific code based on
whether the classpath resource was a directory, zip, or a jar file.



On Mon, Jan 15, 2018 at 6:13 PM, Bessie, Timothy
 wrote:
> Sorry, I should clarify - there doesn't appear to be a way to know what 
> classpath is being used, modify it, etc.  It's a black box we have little 
> control over.
>
> - Tim
>
> -Original Message-
> From: Bessie, Timothy [mailto:tim.bes...@mckesson.com]
> Sent: Monday, January 15, 2018 14:32
> To: Velocity Developers List 
> Subject: RE: Problem in Eclipse with JBoss's java2ws using velocity - "The 
> specified logger class org.apache.velocity.runtime.log.NullLogSystem does not 
> implement the org.apache.velocity.runtime.log.LogChute interface"
>
>>> Claude Brisson: Most probably, you have several instances of Velocity in 
>>> your classpath, an 1.7 and an older one somewhere else.
>> That's what I suspected at first as well; I testing by removing all but a 
>> single instance of Velocity 1.7 (I renamed all other instances - I'm not 
>> sure if I have direct control over the classpath that this plugin uses, or 
>> if I do I'm not sure how to modify it, as I don't think it uses the project 
>> classpath directly).  Got the same stacktrace, unfortunately.
> I think it's worth spending some time finding out which classpath is JBoss 
> using. Since I'm not using it personally I can't help you on this, sometimes 
> it's just as simple as printing the CLASSPATH environment variable.
>
> I'm not sure if that's possible - this is the classpath being used by the 
> WebService wizard plugin; I see no way to modify its default behavior.  We're 
> going to lodge a support ticket with Red Hat to see if they can advise.
>
> - Tim
>

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

Velocity 2 press release announcement

[Mike Kienenberger]

It might be worthwhile to send a message to press@ to start the
process of creating a velocity 2 press release.

MyFaces Tobago is working through that process now, and while I am not
directly involved, it appears that Sally will prepare a draft press
release for you and someone from velocity would need to help her fill
in the details.

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

Re: [tools] Tools reeng

[Mike Kienenberger]

On Thu, Nov 17, 2016 at 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:
> - 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.

Tools are lightweight and often trivial in implementation.   I see
nothing wrong with a single method on a tool.   If the tool is
appropriately-named, other functionality may be added later.

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

Re: Logging configuration

[Mike Kienenberger]

+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

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

[Mike Kienenberger]

I maintain a project that uses struts tools, but my version of struts
tools (like my version of velocity and struts) is so old that
maintaining the "current" struts tools version isn't useful to me.  I
maintained my own version of my tools on those rare occasions where it
was necessary.   If no one has submitted any patches "recently" I'd
say stop supporting it.

On Mon, Nov 7, 2016 at 9:20 AM, Nathan Bubna  wrote:
> It could be worth asking over on Struts. Though i think it's more important
> to know if we have any developers interested in supporting/maintaining it
> than to know if anyone is using it. I know i'm uninterested in working on
> it.
>
> On Mon, Nov 7, 2016 at 2: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
>>
>>
>>
>> -
>> 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

[Mike Kienenberger]

Don't revert on my behalf.   It doesn't matter to me if I'm listed as
a committer in the pom, and it can always be corrected in a future
release.

But did you ever publish the staging URL?  I don't remember seeing it.

On Fri, Oct 14, 2016 at 8:56 AM, Claude Brisson  wrote:
> I change my vote to -1: I forgot Mike as new commiter... (sorry about that,
> Mike!). Also, Dishara (who worked on the JSR 223 scripting) is not listed.
>
> Ah, and Antonio asked to become emeritus (but the change hasn't been pushed
> upwards, I think only Nathan can do it).
>
> If you don't mind, I'll revert and redo the release procedure, keeping your
> votes (3 binding votes from Sergiu, Nathan and myself), and publishing the
> master pom artifact directly with those little changes. If this democratic
> rules breaching does disturb anyone, please chime in.
>
>   Claude
>
>
>
> On 11/10/2016 14:11, 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-master-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
>>
>>
>
>
> -
> 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

[Mike Kienenberger]

I took a look at the MyFaces release page, which in turn points to the
following url.  Starting at this section, it does look like you now
have all of the pieces you need in place:  prepare the release,
perform the release, close the respository, take the vote.

http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-release

3 - Prepare the release

mvn release:clean
mvn release:prepare

Note: Preparing the release will create the new tag in SVN,
automatically checking in on your behalf.

Note: If you're located in Europe then release:prepare may fail with
'Unable to tag SCM' and ' svn: No such revision X '. Wait 10 seconds
and run mvn release:prepare again.

4 - Stage the release for a vote

mvn release:perform

The release will automatically be inserted into a temporary staging
repository for you. See the Nexus staging documentation for full
details.

Now you must close the staging repository to indicate to Nexus that
the build is done and to make the artifacts available. Follow the
steps in Closing the Staged Repository to close your new repository,
this will allow your community to VOTE on the staged atrifacts.


On Tue, Oct 11, 2016 at 9:45 AM, Antonio Petrelli
 wrote:
> 2016-10-11 15:31 GMT+02:00 Sergiu Dumitriu :
>
>> That's normal, that URL points to a virtual push-only directory, and you
>> also need a staging ID to identify which staging repo to push to. When
>> using the browser, a new random ID was generated. It seems that nexus is
>> behind it, you must log in and look at the staging repos to actually
>> publish the staged release.
>>
>
> But before publishing (release) the package, it must be closed, the vote
> should end and, if succesful, you can release it.
>
> Antonio

-
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

[Mike Kienenberger]

On Tue, Oct 11, 2016 at 8:11 AM, Claude Brisson  wrote:
> (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...).

Here's where the myfaces pom ended up on the last release (Nov 2015).
Maybe this can be of some help?

https://repository.apache.org/content/groups/staging/org/apache/myfaces/myfaces/16/



There are some checksum files which have today's timestamp here, but I
don't see anything else:

https://repository.apache.org/content/groups/staging/org/apache/velocity/velocity/
https://repository.apache.org/content/groups/staging/org/apache/velocity/velocity-tools/

I would have expected to see a velocity/2 directory based on what MyFaces did.

-
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

[Mike Kienenberger]

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/resources/gobbling/if.vtl
> 
> velocity/engine/trunk/velocity-engine-core/src/test/resources/gobbling/macro.vtl
> 
> velocity/engine/trunk/velocity-engine-core/src/test/resources/gobbling/set.vtl
> 
> velocity/engine/trunk/velocity-engine-core/src/test/resources/gobbling/structured.vtl
> Modified:
> 
> velocity/engine/trunk/velocity-engine-core/src/main/java/org/apache/velocity/runtime/RuntimeConstants.java
> 
> velocity/engine/trunk/velocity-engine-core/src/main/java/org/apache/velocity/runtime/RuntimeInstance.java
> 
> 

[jira] [Commented] (VELOCITY-816) Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger commented on VELOCITY-816:


I think a 2.x release is high on Claude's priority list which is why he has 
been busy resolving so many issues, but your best bet is to ask on the velocity 
dev or user mailing list.

> Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.
> --
>
> Key: VELOCITY-816
> URL: https://issues.apache.org/jira/browse/VELOCITY-816
> Project: Velocity
>  Issue Type: Improvement
>Reporter: Craig P. Motlin
>Assignee: Mike Kienenberger
> Fix For: 1.7.x
>
>




--
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-816) Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger commented on VELOCITY-816:


Oops.  Thanks for correcting the fix version.   I had meant to do that as well.



> Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.
> --
>
> Key: VELOCITY-816
> URL: https://issues.apache.org/jira/browse/VELOCITY-816
> Project: Velocity
>  Issue Type: Improvement
>Reporter: Craig P. Motlin
>Assignee: Mike Kienenberger
> Fix For: 1.7.x
>
>




--
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] [Updated] (VELOCITY-816) Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-816:
---
Summary: Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.  (was: 
Upgrade commons-lang from 2.4 to 2.6.)

> Upgrade commons-lang from 2.4 to 2.6 for Velocity 1.x.
> --
>
> Key: VELOCITY-816
> URL: https://issues.apache.org/jira/browse/VELOCITY-816
> Project: Velocity
>  Issue Type: Improvement
>Reporter: Craig P. Motlin
>Assignee: Mike Kienenberger
> Fix For: 1.7.x
>
>




--
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: svn commit: r1752882 - in /velocity/engine/trunk/velocity-engine-scripting: ./ src/main/java/org/apache/velocity/script/ src/main/java/org/apache/velocity/script/util/ src/test/java/org/apache/vel

[Mike Kienenberger]

The only concern I have is adding the APL to the existing file.  I
think everything in the file has to stay under the original license,
even if you modify it.

We should keep the Sun license text and also list it in the notices file.


On Sat, Jul 16, 2016 at 3:25 AM, Claude Brisson <cla...@renegat.net> wrote:
> I agree, but does it means we should *remove* the license text?
>
> I read "Redistributions of source code must retain the above copyright
> notice". So I was under the impression that the way to go is to have both
> notices in the file.
>
>
>   Claude
>
>
> On 16/07/2016 00:43, Mike Kienenberger wrote:
>>
>> Signing off that this Sun license falls under A category despite not
>> being explicitly listed.
>>
>> On Fri, Jul 15, 2016 at 6:31 PM,  <cbris...@apache.org> wrote:
>>>
>>> Author: cbrisson
>>> Date: Fri Jul 15 22:30:59 2016
>>> New Revision: 1752882
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1752882=rev
>>> Log:
>>> review (ahem... rewrite using Sun provided example) scripting interface
>>>
>>> Added:
>>>  velocity/engine/trunk/velocity-engine-scripting/src/test/resources/
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/test/resources/velocity.properties
>>>- copied unchanged from r1752841,
>>> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/resources/velocity.properties
>>> Removed:
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityBindings.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityCompilable.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityCompiledScript.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityInvocable.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptContext.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptException.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/util/
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/ScriptEngineFactoryTest.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/resources/velocity.properties
>>> Modified:
>>>  velocity/engine/trunk/velocity-engine-scripting/pom.xml
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptEngine.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptEngineFactory.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/ScriptEngineTest.java
>>>
>>> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/VelocityScriptContextTest.java
>>>
>>> Modified: velocity/engine/trunk/velocity-engine-scripting/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/velocity/engine/trunk/velocity-engine-scripting/pom.xml?rev=1752882=1752881=1752882=diff
>>>
>>> ==
>>> --- velocity/engine/trunk/velocity-engine-scripting/pom.xml (original)
>>> +++ velocity/engine/trunk/velocity-engine-scripting/pom.xml Fri Jul 15
>>> 22:30:59 2016
>>> @@ -21,26 +21,60 @@
>>>   -->
>>>   http://maven.apache.org/POM/4.0.0;
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>>> -4.0.0
>>> -
>>> -org.apache.velocity
>>> -velocity-engine-parent
>>> -2.0.0-SNAPSHOT
>>> -
>>> -velocity-engine-scripting
>>> +  4.0.0
>>> +  
>>> +org.apache.velocity
>>> +velocity-engine-parent
>>>   2.0.0-SNAPSHOT
>>> -Apache Velocity - JSR 223 Scripting
>>> -
>>> -
>>> -org.apache.velocity
>>> -velocity-engine-

Re: svn commit: r1752882 - in /velocity/engine/trunk/velocity-engine-scripting: ./ src/main/java/org/apache/velocity/script/ src/main/java/org/apache/velocity/script/util/ src/test/java/org/apache/vel

[Mike Kienenberger]

Signing off that this Sun license falls under A category despite not
being explicitly listed.

On Fri, Jul 15, 2016 at 6:31 PM,   wrote:
> Author: cbrisson
> Date: Fri Jul 15 22:30:59 2016
> New Revision: 1752882
>
> URL: http://svn.apache.org/viewvc?rev=1752882=rev
> Log:
> review (ahem... rewrite using Sun provided example) scripting interface
>
> Added:
> velocity/engine/trunk/velocity-engine-scripting/src/test/resources/
> 
> velocity/engine/trunk/velocity-engine-scripting/src/test/resources/velocity.properties
>   - copied unchanged from r1752841, 
> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/resources/velocity.properties
> Removed:
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityBindings.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityCompilable.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityCompiledScript.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityInvocable.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptContext.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptException.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/util/
> 
> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/ScriptEngineFactoryTest.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/resources/velocity.properties
> Modified:
> velocity/engine/trunk/velocity-engine-scripting/pom.xml
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptEngine.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptEngineFactory.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/ScriptEngineTest.java
> 
> velocity/engine/trunk/velocity-engine-scripting/src/test/java/org/apache/velocity/script/test/VelocityScriptContextTest.java
>
> Modified: velocity/engine/trunk/velocity-engine-scripting/pom.xml
> URL: 
> http://svn.apache.org/viewvc/velocity/engine/trunk/velocity-engine-scripting/pom.xml?rev=1752882=1752881=1752882=diff
> ==
> --- velocity/engine/trunk/velocity-engine-scripting/pom.xml (original)
> +++ velocity/engine/trunk/velocity-engine-scripting/pom.xml Fri Jul 15 
> 22:30:59 2016
> @@ -21,26 +21,60 @@
>  -->
>  http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> -4.0.0
> -
> -org.apache.velocity
> -velocity-engine-parent
> -2.0.0-SNAPSHOT
> -
> -velocity-engine-scripting
> +  4.0.0
> +  
> +org.apache.velocity
> +velocity-engine-parent
>  2.0.0-SNAPSHOT
> -Apache Velocity - JSR 223 Scripting
> -
> -
> -org.apache.velocity
> -velocity-engine-core
> -2.0.0-SNAPSHOT
> -
> -
> -junit
> -junit
> -4.8.2
> -test
> -
> -
> +  
> +  velocity-engine-scripting
> +  2.0.0-SNAPSHOT
> +  Apache Velocity - JSR 223 Scripting
> +  
> +
> +  org.apache.velocity
> +  velocity-engine-core
> +  2.0.0-SNAPSHOT
> +
> +
> +  junit
> +  junit
> +  4.8.2
> +  test
> +
> +
> +  org.slf4j
> +  slf4j-simple
> +  1.7.12
> +  test
> +
> +  
> +  
> +
> +  
> +org.apache.maven.plugins
> +maven-surefire-plugin
> +
> +  
> +
> +  test.resources.dir
> +  ${project.build.directory}
> +
> +  
> +
> +
> +  
> +integration-test
> +integration-test
> +
> +  test
> +
> +
> +  false
> +
> +  
> +
> +  
> +
> +  
>  
>
> Modified: 
> velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptEngine.java
> URL: 
> http://svn.apache.org/viewvc/velocity/engine/trunk/velocity-engine-scripting/src/main/java/org/apache/velocity/script/VelocityScriptEngine.java?rev=1752882=1752881=1752882=diff
> ==
> --- 
> 

Re: [RESULT] [VOTE] New site layout - Apache CMS

[Mike Kienenberger]

On Thu, May 19, 2016 at 2:38 AM, Perry Tew  wrote:
> Hey man, it's cool.  I figured since I was just a lurker I didn't count.  :)
> But really, I shouldn't count.  I've only taken from this project, never
> given, so no apologies.
> The site looks stellar, btw.  Great job.

Perry, "binding" is a legal term, not a value judgement.  Your opinion
on this matter is important, especially since you are an end user of
velocity.

However, only members of the project management committee (PMC) have
the legal authority to make certain decisions, such as approving
releases or adding new committers/PMC members.

In this particular decision, however, I don't think "binding" applies
as this is more of a technical decision than a legal one.

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

Re: [RESULT] [VOTE] New site layout - Apache CMS

[Mike Kienenberger]

I'm still a non-binding vote as well.

On Thu, May 19, 2016 at 2:32 AM, Claude Brisson <cla...@renegat.net> wrote:
>> switch to this new site and to the Apache CMS?
>
> The vote was launched more than 48h ago. We already have four +1 binding
> votes (Mike Kienenberger, Nathan Bubna, Will Glass-Husain and Claude
> Brisson), plus one +1 non-binding vote (Jacob Champlin).
>
> So let's do it! I open the request to infra.
>
>
>   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: [VOTE] New site layout - Apache CMS

[Mike Kienenberger]

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

> Now to the vote: switch to this new site and to the Apache CMS?
>
> [  ] -1
> [  ] 0
> [  ]+1

+1 from me.  I agree that the old site was no longer maintainable.   I
looked at it at one point but couldn't figure it out.

-
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

[Mike Kienenberger]

Chris,

Read the whole thread.   My understanding is that serialization of
static commons-logging was the original problem needing fixed. slf4j
doesn't have that issue.

On Mon, Aug 31, 2015 at 1:41 PM, Christopher Schultz
 wrote:
> Claude,
>
> On 8/20/15 3:12 PM, Claude Brisson wrote:
>> 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.
>
> A little late to the (logging) party, and this may be a bit off-topic,
> but why bother using a Velocity-specific Logging facade when
> commons-logging was built for that purpose and it is already pluggable?
>
> Frederic Brier posted earlier in the summer about /removing/
> commons-logging, so there's obviously some contention on how this all
> ought to be done.
>
> -chris
>

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

Go ahead and apply your patches

[Mike Kienenberger]

Bill,

You're a committer now, please apply any patches directly to svn that
you think are needed.

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

[jira] [Commented] (VELTOOLS-154) Bad tool causes velocity servlet to fail to initialize, chew 100% CPU

[Mike Kienenberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702350#comment-14702350
 ] 

Mike Kienenberger commented on VELTOOLS-154:


Mohammad,

It's unlikely that your issue is related to this problem   This issue is 
triggered by an incorrectly-designed velocity tool.  The issue only exists to 
provide a better error message when this situation occurs.

I recommend you bring it up your specific issue with your specific details on 
the user@velocity mailing list so we can discuss it there and determine whether 
it is a bug or a configuration issue.   See 
http://velocity.apache.org/engine/devel/mail-lists.html for information on how 
to subscribe to the mailing list and post questions.

 Bad tool causes velocity servlet to fail to initialize, chew 100% CPU
 -

 Key: VELTOOLS-154
 URL: https://issues.apache.org/jira/browse/VELTOOLS-154
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityView
Affects Versions: 2.0
 Environment: Sun/Oracle Java 1.7.0_09: Java HotSpot(TM) 64-Bit Server 
 VM version 23.5-b02
 Velocity 1.7
 Velocity Tools 2.0 + a few (unrelated)  backports from trunk
Reporter: Christopher Schultz
Priority: Minor

 I added a class to my tools.xml which can't be instantiated (because it 
 doesn't have a no-arg constructor). The result when accessing my first 
 velocity template was a nearly endless stack trace like this:
 Caused by: org.apache.velocity.tools.config.ConfigurationException: Couldn't 
 instantiate instance of tool for: Unusable Tool 'forwardBuilder' = [My Tool 
 Class] with 1 properties [key -auto- forwardBuilder; 
 ](java.lang.InstantiationException: com.chadis.tools.struts.ForwardBuilder)
 at 
 org.apache.velocity.tools.config.ToolConfiguration.validate(ToolConfiguration.java:356)
 at 
 org.apache.velocity.tools.config.CompoundConfiguration.validate(CompoundConfiguration.java:115)
 at 
 org.apache.velocity.tools.config.ToolboxConfiguration.validate(ToolboxConfiguration.java:108)
 at 
 org.apache.velocity.tools.config.CompoundConfiguration.validate(CompoundConfiguration.java:115)
 at 
 org.apache.velocity.tools.config.FactoryConfiguration.validate(FactoryConfiguration.java:232)
 at 
 org.apache.velocity.tools.ToolboxFactory.configure(ToolboxFactory.java:80)
 at 
 org.apache.velocity.tools.ToolManager.configure(ToolManager.java:90)
 at 
 org.apache.velocity.tools.view.ViewToolManager.configure(ViewToolManager.java:213)
 at 
 org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:508)
 at 
 org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:313)
 at 
 org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:213)
 at 
 org.apache.velocity.tools.view.ServletUtils.createView(ServletUtils.java:156)
 at 
 org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:142)
 at 
 org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:104)
 at 
 org.apache.velocity.tools.view.VelocityViewServlet.getVelocityView(VelocityViewServlet.java:155)
 at 
 org.apache.velocity.tools.view.VelocityViewServlet.init(VelocityViewServlet.java:122)
 at 
 org.apache.velocity.tools.view.VelocityLayoutServlet.init(VelocityLayoutServlet.java:133)
 at 
 org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266)
 at [...]
 Eventually, the thread somehow recovers but not before generating about 800 
 of the above Caused by stack elements. I was actually expecting a 
 StackOverflowError at some point, but it never came.



--
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] [Closed] (VELOCITY-865) I am new velocity .

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger closed VELOCITY-865.
--

 I am new velocity . 
 

 Key: VELOCITY-865
 URL: https://issues.apache.org/jira/browse/VELOCITY-865
 Project: Velocity
  Issue Type: New Feature
  Components: Documentation
Affects Versions: 1.7.x
Reporter: phuongphally
 Fix For: 1.7.x


 I am new velocity. I need explain from you. please help me please , I don't 
 know why we need to use it.



--
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] [Resolved] (VELOCITY-865) I am new velocity .

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger resolved VELOCITY-865.

Resolution: Not A Problem

Please post questions and hold discussions about using Velocity to the Velocity 
user mailing list.

See this page for instructions:

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


 I am new velocity . 
 

 Key: VELOCITY-865
 URL: https://issues.apache.org/jira/browse/VELOCITY-865
 Project: Velocity
  Issue Type: New Feature
  Components: Documentation
Affects Versions: 1.7.x
Reporter: phuongphally
 Fix For: 1.7.x


 I am new velocity. I need explain from you. please help me please , I don't 
 know why we need to use it.



--
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: Proposal to add Features to the Apache Velocity Scripting Language

[Mike Kienenberger]

Pick something specific and propose the idea here on the dev@velocity list.
If no one objects, we'll have you open a JIRA issue and you can submit
your changes as a unified diff patch.

Activity has been picking up recently, so you've chosen a good time.

On Sat, Jun 27, 2015 at 5:30 AM, Shreyans Sheth
shreyans.sh...@gmail.com wrote:
 Hello,
 I wish to add templates and further refine the Velocity Scripting Language.
 However, I have noticed that this project has not been active for quite
 some time. I am proficient at JAVA and want to start contributing right
 away. This is my first open source contribution so how exactly do i start?

 --
 Shreyans Sheth

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

[jira] [Commented] (VELTOOLS-166) Syntax error in DOAP file release section

[Mike Kienenberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582673#comment-14582673
 ] 

Mike Kienenberger commented on VELTOOLS-166:


I'll go ahead and fix it since I did the same thing for MyFaces.  But I don't 
have jira permissions for VELTOOLS yet.

Are there any similar requests for other Velocity projects queued up?  I joined 
the velocity project after you entered all the DOAP jiras.


 Syntax error in DOAP file release section
 -

 Key: VELTOOLS-166
 URL: https://issues.apache.org/jira/browse/VELTOOLS-166
 Project: Velocity Tools
  Issue Type: Bug
 Environment: 
 http://svn.apache.org/repos/asf/velocity/site/site/doap_tools.rdf
Reporter: Sebb

 DOAP files can contain details of multiple release Versions, however each 
 must be listed in a separate release section, for example:
 release
   Version
 nameApache XYZ/name
 created2015-02-16/created
 revision1.6.2/revision
   /Version
 /release
 release
   Version
 nameApache XYZ/name
 created2014-09-24/created
 revision1.6.1/revision
   /Version
 /release
 Please can the project DOAP be corrected accordingly?
 Thanks.



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

Need to be added to the VELTOOLS jira admin role

[Mike Kienenberger]

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

[jira] [Assigned] (VELTOOLS-166) Syntax error in DOAP file release section

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reassigned VELTOOLS-166:
--

Assignee: Mike Kienenberger

 Syntax error in DOAP file release section
 -

 Key: VELTOOLS-166
 URL: https://issues.apache.org/jira/browse/VELTOOLS-166
 Project: Velocity Tools
  Issue Type: Bug
 Environment: 
 http://svn.apache.org/repos/asf/velocity/site/site/doap_tools.rdf
Reporter: Sebb
Assignee: Mike Kienenberger

 DOAP files can contain details of multiple release Versions, however each 
 must be listed in a separate release section, for example:
 release
   Version
 nameApache XYZ/name
 created2015-02-16/created
 revision1.6.2/revision
   /Version
 /release
 release
   Version
 nameApache XYZ/name
 created2014-09-24/created
 revision1.6.1/revision
   /Version
 /release
 Please can the project DOAP be corrected accordingly?
 Thanks.



--
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: Need to be added to the VELTOOLS jira admin role

[Mike Kienenberger]

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

[jira] [Assigned] (VELOCITY-859) Syntax error in DOAP file release section

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reassigned VELOCITY-859:
--

Assignee: Mike Kienenberger

 Syntax error in DOAP file release section
 -

 Key: VELOCITY-859
 URL: https://issues.apache.org/jira/browse/VELOCITY-859
 Project: Velocity
  Issue Type: Bug
 Environment: 
 http://svn.apache.org/repos/asf/velocity/site/site/doap_engine.rdf
Reporter: Sebb
Assignee: Mike Kienenberger

 DOAP files can contain details of multiple release Versions, however each 
 must be listed in a separate release section, for example:
 release
   Version
 nameApache XYZ/name
 created2015-02-16/created
 revision1.6.2/revision
   /Version
 /release
 release
   Version
 nameApache XYZ/name
 created2014-09-24/created
 revision1.6.1/revision
   /Version
 /release
 Please can the project DOAP be corrected accordingly?
 Thanks.



--
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: Need to be added to the VELTOOLS jira admin role

[Mike Kienenberger]

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

[jira] [Closed] (VELTOOLS-166) Syntax error in DOAP file release section

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger closed VELTOOLS-166.
--
Resolution: Fixed

Added release tags around each set of version tags.

 Syntax error in DOAP file release section
 -

 Key: VELTOOLS-166
 URL: https://issues.apache.org/jira/browse/VELTOOLS-166
 Project: Velocity Tools
  Issue Type: Bug
 Environment: 
 http://svn.apache.org/repos/asf/velocity/site/site/doap_tools.rdf
Reporter: Sebb
Assignee: Mike Kienenberger

 DOAP files can contain details of multiple release Versions, however each 
 must be listed in a separate release section, for example:
 release
   Version
 nameApache XYZ/name
 created2015-02-16/created
 revision1.6.2/revision
   /Version
 /release
 release
   Version
 nameApache XYZ/name
 created2014-09-24/created
 revision1.6.1/revision
   /Version
 /release
 Please can the project DOAP be corrected accordingly?
 Thanks.



--
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] [Closed] (VELOCITY-859) Syntax error in DOAP file release section

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger closed VELOCITY-859.
--
Resolution: Fixed

Added release tags around each set of version tags.

 Syntax error in DOAP file release section
 -

 Key: VELOCITY-859
 URL: https://issues.apache.org/jira/browse/VELOCITY-859
 Project: Velocity
  Issue Type: Bug
 Environment: 
 http://svn.apache.org/repos/asf/velocity/site/site/doap_engine.rdf
Reporter: Sebb
Assignee: Mike Kienenberger

 DOAP files can contain details of multiple release Versions, however each 
 must be listed in a separate release section, for example:
 release
   Version
 nameApache XYZ/name
 created2015-02-16/created
 revision1.6.2/revision
   /Version
 /release
 release
   Version
 nameApache XYZ/name
 created2014-09-24/created
 revision1.6.1/revision
   /Version
 /release
 Please can the project DOAP be corrected accordingly?
 Thanks.



--
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: Need to be added to the VELTOOLS jira admin role

[Mike Kienenberger]

Thanks.  I know what a pain it is to have to assign roles to several
different projects -- I have to assign people to 11 different
subprojects for MyFaces :)

On Thu, Jun 11, 2015 at 8:08 PM, Nathan Bubna nbu...@gmail.com wrote:
 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



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

Re: general@velocity mailing list

[Mike Kienenberger]

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: Changing velocity web site

[Mike Kienenberger]

Thanks for pointing that one out.  I missed it despite Will mentioning
committer section.

I was looking at this one:

http://wiki.apache.org/velocity/VelocitySite

So that helps.

In the old days, the site was build in pieces, checked in, and then
merged using zones.

So the trick will be to either move that merging process back to the
local system or to directly push the pieces into the right place in
site/production.

I'll see if I can find a copy of /export/home/velocity/bin/*.sh in svn


On Tue, Jun 9, 2015 at 4:26 PM, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
 Especially http://wiki.apache.org/velocity/RebuildSites

 On 06/09/2015 04:18 PM, Will Glass-Husain wrote:
 Hi Mike,

 Have you reviewed the nots on the wiki?  They are old but may be of use.
 Look at Committer info section on this page.

 http://wiki.apache.org/velocity/

 WILL

 On Tue, Jun 9, 2015 at 12:41 PM, Mike Kienenberger mkien...@gmail.com
 wrote:

 I've done some poking around.

 https://svn.apache.org/repos/asf/velocity/site/production is indeed
 the svnsubpub directory: any changes committed here are instantly
 deployed to the web site.

 https://svn.apache.org/repos/asf/velocity/site/site appears to be the
 maven project to build the site.

 I've had limited success with this.   If I compare the target/site/*
 files with the production/* files, I find:

 - The front page files are rebuilt with an updated copyright and last
 published date, but they lose the Project Documentation section
 (project info and project report links)

 - Same for the reports/ directory contents.

 - Many files are missing.

 I'm guessing that subprojects need to build the missing pieces (each
 seems to have a src/site directory).   I attempted to build site using
 mvn on trunk (2.x) but generated pages that look very different from
 what's deployed.   I attempted to build site using mvn on 1.x (had to
 upgrade findbugs-maven-plugin to what 2.x was using to make the build
 work) and got a mostly blank page with a header that still looked
 different.   So I'm not sure how to build the web site so that it
 matches what's currently out there.

 If anyone has any hints, please let me know.


 On Mon, Jun 8, 2015 at 10:38 AM, Mike Kienenberger mkien...@gmail.com
 wrote:
 On Sun, Jun 7, 2015 at 7:11 PM, Will Glass-Husain
 wglasshus...@gmail.com wrote:
 The build process for the site is very old -- is that still applicable
 after the svnpubsub change?

 svnpubsub makes it so that whenever you commit to the svnpubsub
 directory, those changes are immediately pushed out into the live web
 site.

 So it's more of a change in how pages are published than a change in
 how pages are created.I haven't looked that the build process for
 the site, but I would guess only the deployment stage needs to be
 updated.

 -
 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: Changing velocity web site

[Mike Kienenberger]

Thanks.  I wasn't aware of that page.

Unfortunately, it confirms what I've guessed so far by reading through
the existing maven site docs + experimentation, without actually
providing the missing pieces :)

Everything past the site module is marked TODO

The one new piece of information I see there is a reference to
building engine site docs with ant but publishing via maven -- I'll
see if I can track that one down.

On Tue, Jun 9, 2015 at 4:18 PM, Will Glass-Husain
wglasshus...@gmail.com wrote:
 Hi Mike,

 Have you reviewed the nots on the wiki?  They are old but may be of use.
 Look at Committer info section on this page.

 http://wiki.apache.org/velocity/

 WILL

 On Tue, Jun 9, 2015 at 12:41 PM, Mike Kienenberger mkien...@gmail.com
 wrote:

 I've done some poking around.

 https://svn.apache.org/repos/asf/velocity/site/production is indeed
 the svnsubpub directory: any changes committed here are instantly
 deployed to the web site.

 https://svn.apache.org/repos/asf/velocity/site/site appears to be the
 maven project to build the site.

 I've had limited success with this.   If I compare the target/site/*
 files with the production/* files, I find:

 - The front page files are rebuilt with an updated copyright and last
 published date, but they lose the Project Documentation section
 (project info and project report links)

 - Same for the reports/ directory contents.

 - Many files are missing.

 I'm guessing that subprojects need to build the missing pieces (each
 seems to have a src/site directory).   I attempted to build site using
 mvn on trunk (2.x) but generated pages that look very different from
 what's deployed.   I attempted to build site using mvn on 1.x (had to
 upgrade findbugs-maven-plugin to what 2.x was using to make the build
 work) and got a mostly blank page with a header that still looked
 different.   So I'm not sure how to build the web site so that it
 matches what's currently out there.

 If anyone has any hints, please let me know.


 On Mon, Jun 8, 2015 at 10:38 AM, Mike Kienenberger mkien...@gmail.com
 wrote:
  On Sun, Jun 7, 2015 at 7:11 PM, Will Glass-Husain
  wglasshus...@gmail.com wrote:
  The build process for the site is very old -- is that still applicable
  after the svnpubsub change?
 
  svnpubsub makes it so that whenever you commit to the svnpubsub
  directory, those changes are immediately pushed out into the live web
  site.
 
  So it's more of a change in how pages are published than a change in
  how pages are created.I haven't looked that the build process for
  the site, but I would guess only the deployment stage needs to be
  updated.

 -
 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: Changing velocity web site

[Mike Kienenberger]

On Sun, Jun 7, 2015 at 7:11 PM, Will Glass-Husain
wglasshus...@gmail.com wrote:
 The build process for the site is very old -- is that still applicable
 after the svnpubsub change?

svnpubsub makes it so that whenever you commit to the svnpubsub
directory, those changes are immediately pushed out into the live web
site.

So it's more of a change in how pages are published than a change in
how pages are created.I haven't looked that the build process for
the site, but I would guess only the deployment stage needs to be
updated.

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

[jira] [Reopened] (VELOCITY-862) Rebuilding parser using javacc 4.1 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reopened VELOCITY-862:


Reopening at Nathan's suggestion that we may want to apply this to 2.x

 Rebuilding parser using javacc 4.1 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Resolved] (VELOCITY-861) Improve parser modification and build documentation

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger resolved VELOCITY-861.

Resolution: Fixed

Applied patch to 1.x trunk.   Changed javacc4.2 version to 4.1 in documentation.

 Improve parser modification and build documentation
 ---

 Key: VELOCITY-861
 URL: https://issues.apache.org/jira/browse/VELOCITY-861
 Project: Velocity
  Issue Type: Improvement
  Components: Build, Documentation
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: build-parser-documentation-update.patch


 Removed .../parser/build.sh as this functionality is an out-of-date version 
 of what is found in the main ant build script parser task.
 Added a license header and updated the portions of the 
 build-and-modify-parser readme found in 
 src/java/org/apache/velocity/runtime/parser/BUILD_README.txt.
 Moved improved src/java/org/apache/velocity/runtime/parser/BUILD_README.txt 
 to build/BUILD_PARSER_README.txt as it is not obvious to go looking for 
 documentation in src/java/org/apache/velocity/runtime/parser when you are 
 modifying src/parser and running build/build.xml
 Replaced previous 
 src/java/org/apache/velocity/runtime/parser/BUILD_README.txt with a 
 simplified version that warns about directly modifying files here and points 
 back to build/BUILD_PARSER_README.txt.



--
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] [Updated] (VELOCITY-861) Improve parser modification and build documentation

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-861:
---
Affects Version/s: (was: 1.7)
   1.x

 Improve parser modification and build documentation
 ---

 Key: VELOCITY-861
 URL: https://issues.apache.org/jira/browse/VELOCITY-861
 Project: Velocity
  Issue Type: Improvement
  Components: Build, Documentation
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: build-parser-documentation-update.patch


 Removed .../parser/build.sh as this functionality is an out-of-date version 
 of what is found in the main ant build script parser task.
 Added a license header and updated the portions of the 
 build-and-modify-parser readme found in 
 src/java/org/apache/velocity/runtime/parser/BUILD_README.txt.
 Moved improved src/java/org/apache/velocity/runtime/parser/BUILD_README.txt 
 to build/BUILD_PARSER_README.txt as it is not obvious to go looking for 
 documentation in src/java/org/apache/velocity/runtime/parser when you are 
 modifying src/parser and running build/build.xml
 Replaced previous 
 src/java/org/apache/velocity/runtime/parser/BUILD_README.txt with a 
 simplified version that warns about directly modifying files here and points 
 back to build/BUILD_PARSER_README.txt.



--
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] [Updated] (VELOCITY-862) Rebuilding parser using javacc 4.1 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-862:
---
Fix Version/s: 1.x

 Rebuilding parser using javacc 4.1 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Updated] (VELOCITY-862) Rebuilding parser using javacc 4.1 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-862:
---
Summary: Rebuilding parser using javacc 4.1 loses Node import  (was: 
Rebuilding parser using javacc 4.2 loses Node import)

 Rebuilding parser using javacc 4.1 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Updated] (VELOCITY-864) Download and install Apache Rat task in preparation target for ant rat

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-864:
---
Affects Version/s: (was: 1.7.x)
   1.x

 Download and install Apache Rat task in preparation target for ant rat
 

 Key: VELOCITY-864
 URL: https://issues.apache.org/jira/browse/VELOCITY-864
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
 Attachments: apache-rat-download-and-define_v2.patch


 Download and install the Apache Rat task in preparation target for ant rat 
 instead of making the end-user do so.
 I'm not entirely certain if this works in other versions of ant, but it does 
 work in ant 1.9.4 and is described in the rat documentation as the 
 traditional way



--
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] [Assigned] (VELOCITY-864) Download and install Apache Rat task in preparation target for ant rat

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reassigned VELOCITY-864:
--

Assignee: Mike Kienenberger

 Download and install Apache Rat task in preparation target for ant rat
 

 Key: VELOCITY-864
 URL: https://issues.apache.org/jira/browse/VELOCITY-864
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Attachments: apache-rat-download-and-define_v2.patch


 Download and install the Apache Rat task in preparation target for ant rat 
 instead of making the end-user do so.
 I'm not entirely certain if this works in other versions of ant, but it does 
 work in ant 1.9.4 and is described in the rat documentation as the 
 traditional way



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

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

[Mike Kienenberger]

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

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

[Mike Kienenberger]

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: [jira] [Updated] (VELOCITY-864) Download and install Apache Rat task in preparation target for ant rat

[Mike Kienenberger]

The ASF leaves almost all decisions like this up to the individual
projects.   There are only a few must items which have to be
followed (releases build from source, code is owned by the ASF, code
is licensed Apache License, notices for other licenses, brand
management)

As you and I are the active developers, I think we can go with
whatever rule makes the most sense, so long as the rest of the
Velocity PMC doesn't object.

I don't have a strong opinion on that one so we can go with what you
propose.   We just need to agree on what affects means :)


On Tue, Jun 2, 2015 at 10:58 PM, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
 In other projects that I've been involved in, the rule was that affects
 version should point to a released version, and if something doesn't
 affect a release version, then this should be left blank. Does
 Velocity / Apache in general follow a different rule?

 On 06/02/2015 10:53 PM, Mike Kienenberger (JIRA) wrote:

 Mike Kienenberger updated VELOCITY-864:
 ---
 Affects Version/s: (was: 1.7.x)
1.x


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

[jira] [Updated] (VELOCITY-862) Rebuilding parser using javacc 4.1 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-862:
---
Affects Version/s: (was: 1.x)

 Rebuilding parser using javacc 4.1 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Updated] (VELOCITY-863) Regression: #settableft-paren no longer valid grammar

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-863:
---
Affects Version/s: (was: 1.7.x)

 Regression: #settableft-paren no longer valid grammar
 ---

 Key: VELOCITY-863
 URL: https://issues.apache.org/jira/browse/VELOCITY-863
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7
Reporter: Mike Kienenberger
Assignee: Sergiu Dumitriu
 Fix For: 2.x, 1.7.1, 1.x

 Attachments: Parser.jjt-set-directive-followed-by-tab.patch, 
 javacc4.1-ParserTokenManager.java-set-directive-followed-by-tab.patch


 In velocity 1.3.1, tab was considered whitespace between the set directive 
 and the first left-parenthesis.   When the grammar was redesigned in Velocity 
 1.4, the ability to use tab as whitespace after #set was lost.



--
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] [Closed] (VELOCITY-846) Create a branch out of the 1.7 tag.

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger closed VELOCITY-846.
--

Might as well close this as there's nothing further to be done.

 Create a branch out of the 1.7 tag.
 ---

 Key: VELOCITY-846
 URL: https://issues.apache.org/jira/browse/VELOCITY-846
 Project: Velocity
  Issue Type: Bug
  Components: Build, Engine
Reporter: Adrian A.
 Fix For: 1.7.x


 Please create a 1.7.x branch out of the 1.7 tag for the Velocity Engine, 
 since there isn't any, but the trunk was already merged with 2.x changes.
 This would allow us to send you patches easier.
 Thanks in advance.



--
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] [Updated] (VELOCITY-816) Upgrade commons-lang from 2.4 to 2.6.

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-816:
---
Assignee: (was: Mike Kienenberger)

 Upgrade commons-lang from 2.4 to 2.6.
 -

 Key: VELOCITY-816
 URL: https://issues.apache.org/jira/browse/VELOCITY-816
 Project: Velocity
  Issue Type: Improvement
Reporter: Craig P. Motlin
 Fix For: 1.7.x






--
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] [Resolved] (VELOCITY-862) Rebuilding parser using javacc 4.1 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger resolved VELOCITY-862.

Resolution: Fixed

Applied patch to 1.x trunk.

 Rebuilding parser using javacc 4.1 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Updated] (VELOCITY-863) Regression: #settableft-paren no longer valid grammar

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-863:
---
Fix Version/s: 1.x

 Regression: #settableft-paren no longer valid grammar
 ---

 Key: VELOCITY-863
 URL: https://issues.apache.org/jira/browse/VELOCITY-863
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7, 1.7.x
Reporter: Mike Kienenberger
Assignee: Sergiu Dumitriu
 Fix For: 2.x, 1.7.1, 1.x

 Attachments: Parser.jjt-set-directive-followed-by-tab.patch, 
 javacc4.1-ParserTokenManager.java-set-directive-followed-by-tab.patch


 In velocity 1.3.1, tab was considered whitespace between the set directive 
 and the first left-parenthesis.   When the grammar was redesigned in Velocity 
 1.4, the ability to use tab as whitespace after #set was lost.



--
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] [Reopened] (VELOCITY-863) Regression: #settableft-paren no longer valid grammar

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reopened VELOCITY-863:


Adding 1.x fix version

 Regression: #settableft-paren no longer valid grammar
 ---

 Key: VELOCITY-863
 URL: https://issues.apache.org/jira/browse/VELOCITY-863
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7, 1.7.x
Reporter: Mike Kienenberger
Assignee: Sergiu Dumitriu
 Fix For: 2.x, 1.7.1, 1.x

 Attachments: Parser.jjt-set-directive-followed-by-tab.patch, 
 javacc4.1-ParserTokenManager.java-set-directive-followed-by-tab.patch


 In velocity 1.3.1, tab was considered whitespace between the set directive 
 and the first left-parenthesis.   When the grammar was redesigned in Velocity 
 1.4, the ability to use tab as whitespace after #set was lost.



--
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] [Resolved] (VELOCITY-863) Regression: #settableft-paren no longer valid grammar

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger resolved VELOCITY-863.

Resolution: Fixed

Added 1.x fix version

 Regression: #settableft-paren no longer valid grammar
 ---

 Key: VELOCITY-863
 URL: https://issues.apache.org/jira/browse/VELOCITY-863
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7, 1.7.x
Reporter: Mike Kienenberger
Assignee: Sergiu Dumitriu
 Fix For: 2.x, 1.7.1, 1.x

 Attachments: Parser.jjt-set-directive-followed-by-tab.patch, 
 javacc4.1-ParserTokenManager.java-set-directive-followed-by-tab.patch


 In velocity 1.3.1, tab was considered whitespace between the set directive 
 and the first left-parenthesis.   When the grammar was redesigned in Velocity 
 1.4, the ability to use tab as whitespace after #set was lost.



--
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: [jira] [Resolved] (VELOCITY-861) Improve parser modification and build documentation

[Mike Kienenberger]

I like to resolve when fixed in svn and to close when released.
I think it's more meaningful.

On Tue, Jun 2, 2015 at 10:30 PM, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
 Should issues be Resolved or Closed? So far I've been closing them.

 On 06/02/2015 10:25 PM, Mike Kienenberger (JIRA) wrote:

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

 Mike Kienenberger resolved VELOCITY-861.
 
 Resolution: Fixed


 --
 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: svn commit: r1683210 - in /velocity/engine/branches/1.x: build/BUILD_PARSER_README.txt src/java/org/apache/velocity/runtime/parser/BUILD_README.txt src/java/org/apache/velocity/runtime/parser/buil

[Mike Kienenberger]

Yeah, that bothered me as well, but I'm no expert on the parser, so I
didn't want to guess whether it was still applicable.  If I didn't
know, I left the original readme as-is.  Java 3.1 has been required
since 1.5, so it's been wrong for a long time.

Please feel free to improve it further.


On Tue, Jun 2, 2015 at 10:48 PM, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
 On 06/02/2015 10:15 PM, mkien...@apache.org wrote:
 +In the event that something 'serious' changes, such as an AST node is 
 created
 +or altered, it must be *manually* moved to the node subdirectory, and have 
 its
 +package declaration fixed.  This should be an extremely rare event at this 
 point
 +and will change with javacc 2.0.

 Since we already require JavaCC 3.2+ does the will change with javacc
 2.0 part make sense?

 +-gmj

 I'd remove this ^

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

[jira] [Resolved] (VELOCITY-864) Download and install Apache Rat task in preparation target for ant rat

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger resolved VELOCITY-864.

   Resolution: Fixed
Fix Version/s: 1.x

Fixed in 1.x trunk.

I couldn't apply my patch -- I must have mangled it when removing the unrelated 
code changes, so I merged it from my local 1.7.x build and re-tested it.

 Download and install Apache Rat task in preparation target for ant rat
 

 Key: VELOCITY-864
 URL: https://issues.apache.org/jira/browse/VELOCITY-864
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Fix For: 1.x

 Attachments: apache-rat-download-and-define_v2.patch


 Download and install the Apache Rat task in preparation target for ant rat 
 instead of making the end-user do so.
 I'm not entirely certain if this works in other versions of ant, but it does 
 work in ant 1.9.4 and is described in the rat documentation as the 
 traditional way



--
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] [Updated] (VELOCITY-864) Download and install Apache Rat task in preparation target for ant rat

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-864:
---
Affects Version/s: (was: 1.x)

 Download and install Apache Rat task in preparation target for ant rat
 

 Key: VELOCITY-864
 URL: https://issues.apache.org/jira/browse/VELOCITY-864
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Attachments: apache-rat-download-and-define_v2.patch


 Download and install the Apache Rat task in preparation target for ant rat 
 instead of making the end-user do so.
 I'm not entirely certain if this works in other versions of ant, but it does 
 work in ant 1.9.4 and is described in the rat documentation as the 
 traditional way



--
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] [Assigned] (VELOCITY-861) Improve parser modification and build documentation

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reassigned VELOCITY-861:
--

Assignee: Mike Kienenberger

 Improve parser modification and build documentation
 ---

 Key: VELOCITY-861
 URL: https://issues.apache.org/jira/browse/VELOCITY-861
 Project: Velocity
  Issue Type: Improvement
  Components: Build, Documentation
Affects Versions: 1.7
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Attachments: build-parser-documentation-update.patch


 Removed .../parser/build.sh as this functionality is an out-of-date version 
 of what is found in the main ant build script parser task.
 Added a license header and updated the portions of the 
 build-and-modify-parser readme found in 
 src/java/org/apache/velocity/runtime/parser/BUILD_README.txt.
 Moved improved src/java/org/apache/velocity/runtime/parser/BUILD_README.txt 
 to build/BUILD_PARSER_README.txt as it is not obvious to go looking for 
 documentation in src/java/org/apache/velocity/runtime/parser when you are 
 modifying src/parser and running build/build.xml
 Replaced previous 
 src/java/org/apache/velocity/runtime/parser/BUILD_README.txt with a 
 simplified version that warns about directly modifying files here and points 
 back to build/BUILD_PARSER_README.txt.



--
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] [Assigned] (VELOCITY-862) Rebuilding parser using javacc 4.2 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reassigned VELOCITY-862:
--

Assignee: Mike Kienenberger

 Rebuilding parser using javacc 4.2 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Updated] (VELOCITY-862) Rebuilding parser using javacc 4.2 loses Node import

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger updated VELOCITY-862:
---
Affects Version/s: (was: 1.7)
   1.x

 Rebuilding parser using javacc 4.2 loses Node import
 

 Key: VELOCITY-862
 URL: https://issues.apache.org/jira/browse/VELOCITY-862
 Project: Velocity
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.x
Reporter: Mike Kienenberger
Assignee: Mike Kienenberger
 Attachments: build.xml-parser-imports-v3.patch


 JavaCC 4.2 loses the org.apache.velocity.runtime.parser.node.Node import 
 for JJTParserState.java when rebuilding the parser.
 Adding nodepackage=org.apache.velocity.runtime.parser.node to the jjtree 
 ant task in the build script will add the following import automatically 
 which is better than no import or manually adding the import later:
 import org.apache.velocity.runtime.parser.*;



--
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] [Reopened] (VELOCITY-860) Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency build script

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reopened VELOCITY-860:


Adding 1.x fix version

 Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency build script
 ---

 Key: VELOCITY-860
 URL: https://issues.apache.org/jira/browse/VELOCITY-860
 Project: Velocity
  Issue Type: Bug
  Components: Build
Affects Versions: 1.7.x
Reporter: Mike Kienenberger
Assignee: Sergiu Dumitriu
 Fix For: 1.7.1, 1.x

 Attachments: ant-build-system-1.5.x.patch, 
 ant-build-system-1.6.x.patch, ant-build-system-1.7.x.patch


 The URL to the maven jar repositories have changed.
 Update the build properties and build script to use the current location.  
 Note that using the /maven/ location wasn't working for all jars, 
 werken-xpath-0.9.4.jar for example, so it was easier to grab all jars from 
 /maven2/ rather than try to grab some from the older /maven/ location.



--
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] [Resolved] (VELOCITY-860) Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency build script

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger resolved VELOCITY-860.

Resolution: Fixed

Added 1.x fix version

 Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency build script
 ---

 Key: VELOCITY-860
 URL: https://issues.apache.org/jira/browse/VELOCITY-860
 Project: Velocity
  Issue Type: Bug
  Components: Build
Affects Versions: 1.7.x
Reporter: Mike Kienenberger
Assignee: Sergiu Dumitriu
 Fix For: 1.7.1, 1.x

 Attachments: ant-build-system-1.5.x.patch, 
 ant-build-system-1.6.x.patch, ant-build-system-1.7.x.patch


 The URL to the maven jar repositories have changed.
 Update the build properties and build script to use the current location.  
 Note that using the /maven/ location wasn't working for all jars, 
 werken-xpath-0.9.4.jar for example, so it was easier to grab all jars from 
 /maven2/ rather than try to grab some from the older /maven/ location.



--
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: [jira] [Resolved] (VELOCITY-861) Improve parser modification and build documentation

[Mike Kienenberger]

I guess I should be more specific.  Using resolve on fix and close on release:

-- Allows users to see at a glance to know if the bug is unfixed,
fixed but unreleased, or released.

-- Allows the release manager to quickly generate a list of changes.
(At least, I'm guessing it will)

On Tue, Jun 2, 2015 at 10:34 PM, Mike Kienenberger mkien...@gmail.com wrote:
 I like to resolve when fixed in svn and to close when released.
 I think it's more meaningful.

 On Tue, Jun 2, 2015 at 10:30 PM, Sergiu Dumitriu
 sergiu.dumit...@gmail.com wrote:
 Should issues be Resolved or Closed? So far I've been closing them.

 On 06/02/2015 10:25 PM, Mike Kienenberger (JIRA) wrote:

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

 Mike Kienenberger resolved VELOCITY-861.
 
 Resolution: Fixed


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

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

[Mike Kienenberger]

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

[jira] [Assigned] (VELOCITY-816) Upgrade commons-lang from 2.4 to 2.6.

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger reassigned VELOCITY-816:
--

Assignee: Mike Kienenberger

 Upgrade commons-lang from 2.4 to 2.6.
 -

 Key: VELOCITY-816
 URL: https://issues.apache.org/jira/browse/VELOCITY-816
 Project: Velocity
  Issue Type: Improvement
Reporter: Craig P. Motlin
Assignee: Mike Kienenberger
 Fix For: 1.7.x






--
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: [jira] [Commented] (VELOCITY-818) Case-insensitive matching ${object.methodName} == ${object.methodname} == ${object.methodName}

[Mike Kienenberger]

Well, I'm ok if you want to reopen it and do something with it, but I
don't want to leave people with false hope.

I guess I can see why it might be helpful in some cases where a
non-technical user may not understand the need for case-sensitivity.

On Tue, Jun 2, 2015 at 11:38 PM, Sergiu Dumitriu (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/VELOCITY-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570219#comment-14570219
  ]

 Sergiu Dumitriu commented on VELOCITY-818:
 --

 I agree that it doesn't make sense as a default language feature, but this 
 could be an optional uberspector that could be enabled in the configuration.

 Case-insensitive matching ${object.methodName} == ${object.methodname} == 
 ${object.methodName}
 --

 Key: VELOCITY-818
 URL: https://issues.apache.org/jira/browse/VELOCITY-818
 Project: Velocity
  Issue Type: New Feature
  Components: Engine
Affects Versions: 1.7
Reporter: Mark S
  Labels: api-change
   Original Estimate: 4h
  Remaining Estimate: 4h

 I thought I would share the following code with the Apache Velocity 
 community.
 Currently there is no easy way for Velocity to do a case-insensitive match 
 on a property or method.  Below is my implementation to achieve this.
 VelocityContext velocityContext = new VelocityContext();
 {
 context.put( aNumericValue, 1234567890 );
 }
 | If String template = | Then String evaluatedTemplate =  |
 | ${aNumericValue} | 1234567890   |
 | ${anumericvalue} | 1234567890   |
 | ${anumericValue} | 1234567890   |
 | ${aNumericvalue} | 1234567890   |
 | ${aNumericValue.toString()}  | 1234567890   |
 | ${anumericvalue.tostring()}  | 1234567890   |
 -- Setup Snippet --
 Properties p = new Properties();
 p.setProperty( RuntimeConstants.INPUT_ENCODING, DEFAULT_ENCODING );
 p.setProperty( RuntimeConstants.OUTPUT_ENCODING, DEFAULT_ENCODING );
 p.setProperty( RuntimeConstants.UBERSPECT_CLASSNAME,
custom.CustomSecureUberspector ); //$NON-NLS-1$

 VelocityEngine engine = new VelocityEngine( p );
 engine.init();
 RuntimeInstance ri = new RuntimeInstance();
 ri.init( p );
 uberspector = (CustomSecureUberspector)ri.getUberspect();
 -- Setup Snippet --
 -- Call Snippet --
 VelocityContext velocityContext = new VelocityContext();
 {
 context.put( aNumericValue, 1234567890 );
 }
 EventCartridge eventCartridge = new EventCartridge();
 eventCartridge.addEventHandler( new SloppyNameReferenceEventHandler( 
 uberspector ) );
 eventCartridge.addEventHandler( new 
 NullValueReferenceInsertionEventHandler() );
 eventCartridge.attachToContext( velocityContext );
 String template = ${aNumericvalue};
 StringWriter velocityWriter = new StringWriter();
 velocityEngine.evaluate( velocityContext, velocityWriter, LOG, template );
 String evaluatedTemplate = velocityWriter.toString();
 -- Call Snippet --
 -- Supporting Classes Snippet --
 package custom;
 import org.apache.velocity.util.introspection.SecureIntrospectorImpl;
 import org.apache.velocity.util.introspection.SecureUberspector;
 public class CustomSecureUberspector extends SecureUberspector
 {
 public SecureIntrospectorImpl getSecureIntrospector()
 {
 return (SecureIntrospectorImpl)introspector;
 }
 }
 package custom;
 import java.lang.reflect.Method;
 import java.util.ArrayList;
 import java.util.List;
 import org.apache.velocity.app.event.InvalidReferenceEventHandler;
 import org.apache.velocity.context.Context;
 import org.apache.velocity.util.introspection.Info;
 import org.apache.velocity.util.introspection.SecureIntrospectorImpl;
 import custom.CustomSecureUberspector;
 @SuppressWarnings( { unused } )
 public class SloppyNameReferenceEventHandler implements 
 InvalidReferenceEventHandler
 {
 protected CustomSecureUberspector uberspector;
 public SloppyNameReferenceEventHandler( CustomSecureUberspector 
 uberspector )
 {
 this.uberspector = uberspector;
 }
 @Override
 public Object invalidGetMethod( Context context, String reference, 
 Object object, String property, Info info )
 {
 try
 {
 return callMethod( object, property );
 }
 catch ( Exception e )
 {
 return null;
 }
 }
 @Override
 public boolean invalidSetMethod( Context context, String leftReference, 
 String rightReference, Info info )
 {
 // Do nothing
 return false;
 }
 @Override
 public Object invalidMethod( Context context, String 

Changing velocity web site

[Mike Kienenberger]

I am looking at velocity/site to determine what the process is in
order to update it.   It looks like Daniel converted velocity to
svnpubsub in 2014.  I can't find a jira issue in INFRA or VELOCITY
dealing with it, though.

Which directory is the live version?  velocity/site/production?  I can
always commit something and see if necessary.

And are we still using the documented build process?


*163581410/31/14, 1:06 PM20151humbedoohMoving Velocity
site to svnpubsub

-
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

[Mike Kienenberger]

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: r1682669 - in /velocity/engine/trunk/velocity-engine-core/src: main/parser/Parser.jjt test/resources/set/set1.vm test/resources/set/set2.vm

[Mike Kienenberger]

Thanks for the test.

I was getting around to creating one, but hadn't done so yet.

On Sat, May 30, 2015 at 11:03 PM,  sdumit...@apache.org wrote:
 Author: sdumitriu
 Date: Sun May 31 03:03:09 2015
 New Revision: 1682669

 URL: http://svn.apache.org/r1682669
 Log:
 VELOCITY-863: Regression: #settableft-paren no longer valid grammar
 Patch from Mike Kienenberger applied + added test

 Modified:
 velocity/engine/trunk/velocity-engine-core/src/main/parser/Parser.jjt
 velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set1.vm
 velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set2.vm

 Modified: 
 velocity/engine/trunk/velocity-engine-core/src/main/parser/Parser.jjt
 URL: 
 http://svn.apache.org/viewvc/velocity/engine/trunk/velocity-engine-core/src/main/parser/Parser.jjt?rev=1682669r1=1682668r2=1682669view=diff
 ==
 --- velocity/engine/trunk/velocity-engine-core/src/main/parser/Parser.jjt 
 (original)
 +++ velocity/engine/trunk/velocity-engine-core/src/main/parser/Parser.jjt Sun 
 May 31 03:03:09 2015
 @@ -694,7 +694,7 @@ TOKEN:
  DEFAULT, REFERENCE, REFMODIFIER, REFMOD2
  TOKEN:
  {
 -  SET_DIRECTIVE: ( |\t)*  (#set | #{set})  ( )* (
 +  SET_DIRECTIVE: ( |\t)*  (#set | #{set})  ( |\t)* (
  {
  if (! inComment)
  {

 Modified: 
 velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set1.vm
 URL: 
 http://svn.apache.org/viewvc/velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set1.vm?rev=1682669r1=1682668r2=1682669view=diff
 ==
 --- velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set1.vm 
 (original)
 +++ velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set1.vm 
 Sun May 31 03:03:09 2015
 @@ -2,12 +2,12 @@
  ## is not accepted
  set1

 -#set($abc = 123)
 +#set ($abc = 123)
  $abc
 -#set($abc = $boohoo)
 +#set   ($abc = $boohoo)
  $abc

 -#set($map = {})
 +#set($map = {})
  #set($map.foo = foo)
  #set($map.bar = bar)
  $map.foo

 Modified: 
 velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set2.vm
 URL: 
 http://svn.apache.org/viewvc/velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set2.vm?rev=1682669r1=1682668r2=1682669view=diff
 ==
 --- velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set2.vm 
 (original)
 +++ velocity/engine/trunk/velocity-engine-core/src/test/resources/set/set2.vm 
 Sun May 31 03:03:09 2015
 @@ -2,12 +2,12 @@
  ## IS accepted
  set2

 -#set($abc = 123)
 +#set ($abc = 123)
  $abc
 -#set($abc = $boohoo)
 +#set   ($abc = $boohoo)
  $abc

 -#set($map = {})
 +#set($map = {})
  #set($map.foo = foo)
  #set($map.bar = bar)
  $map.foo



-
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

[Mike Kienenberger]

Thanks.   Makes perfect sense now that you've said it :)

On Sun, May 31, 2015 at 3:22 PM, Nathan Bubna nbu...@gmail.com wrote:
 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



-
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

[Mike Kienenberger]

I think for the older branches we don't need to support newer versions
of java.   If someone needs it, then they are probably already using
an ancient version of java, or are willing to get one, or are willing
to make the changes necessary to get it working.   As long as the
build could work with the correct tool-chain installed, we've gone
above and beyond what's necessary.

I have Velocity_1.5_BRANCH building under java 1.8 with the only
change being the download patch using ant jar.   For an ancient
branch, I think that's sufficient.

Making ant test work under Java 1.8 requires a trivial update for
DataSource (what needs to be done is said in the compiler error):

public Logger getParentLogger() throws SQLFeatureNotSupportedException {
throw new SQLFeatureNotSupportedException();
}

and passes all tests but one:

[junit] Test org.apache.velocity.test.issues.VelTools66TestCase FAILED


I suppose we could fix it if you like, though, as it shouldn't break
anything under ancient versions of java, but I'd say leave it alone.
Fixing the build script is reasonable, but changing the code to
provide forward-compatibility isn't something anyone would expect.
So I think that's good enough.


Running ant package on velocity 1.5 using Java 1.8 requires setting
your current java version in the build.properties:

 dist.required.java.version = 1.8

That seems fine the way it is.




On Sun, May 31, 2015 at 5: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

Recent JIRA issues (with patches) by me

[Mike Kienenberger]

Since I'm not certain who, if anyone, is notified of JIRA changes,
here's a list of the items I've been working on.

VELOCITY-864 Download and install Apache Rat task in preparation
target for ant rat
VELOCITY-863 Regression: #settableft-paren no longer valid grammar
VELOCITY-862 Rebuilding parser using javacc 4.2 loses Node import
VELOCITY-861 Improve parser modification and build documentation
VELOCITY-860 Fix Velocity 1.7.x, 1.6.x, 1.5 ant download dependency build script

Things I would like to see happen before a 1.8 release:

-- insure rat passes with an appropriate exclude list
-- fix tests [merging in Frederick's changes and/or Sergiu's changes]
-- compile natively under Java 1.7 [merging in Frederick's changes
and/or Sergiu's changes]
-- update dependencies [merging in Frederick's changes and/or Sergiu's changes]

I will slowly plod toward these goals but any additional help will be
appreciated.

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

No JIRA changes sent to a mailing list?

[Mike Kienenberger]

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?

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

general@velocity mailing list

[Mike Kienenberger]

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

Re: No JIRA changes sent to a mailing list?

[Mike Kienenberger]

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: Successfully building 1.x branches and regenerating parser files

[Mike Kienenberger]

On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger mkien...@gmail.com wrote:
 1.3 and 1.4 won't build without some code changes -- they use enum as
 a variable.

These were generated parser files.  A find and replace of enum to enmr
was all that was needed.   Or going back to java 1.3 :)

 Parser modification also seems possible now, although the large number
 of changes between my generated code and the old generated code seems
 to indicate that I'm still not using the same version of javacc that
 the original code was generated from.  1.6 is a close enough match
 that I suspect it uses javacc 3.2.   That probably means 1.5 was
 generated with something older and 1.7 was generated with something
 newer.

Part of the differences turned out to be code reformatting of the
generated files.  Velocity 1.5 used javacc 3.1.   1.6 used javacc 3.2.
Velocity 1.7 used javacc 4.2 but JJTParserState.java file needs to be
manually reverted manually after running the parser task.   The newly
generated JJTParserState only changes the file checksum and loses the
org.apache.velocity.runtime.parser.node.Node import.

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

Re: Successfully building 1.x branches and regenerating parser files

[Mike Kienenberger]

I've already created issue 860 and I have already attached individual
patches for fixing the build scripts in 1.5, 1.6.x, and 1.7.x
branches.

https://issues.apache.org/jira/browse/VELOCITY-860.

Modifying unusable build files to point to the right download
locations is one thing, but I'm on the fence about whether we should
change the 1.3.1 or 1.4 java files to make them build on newer
versions of java.  Using an older version of java or possibly using a
source  target javac flag leaves them usable as is.   If a person
really wants to make them work under a newer version of java, it's
easy to rename the variables, but that would have to be done each time
the parsing files are regenerated using the older javacc packages.

I am currently in the process of updating the build instructions for
the parser, and removing the old build.sh script -- it only adds
confusion now that the main build script does everything necessary.  I
should be finished with that in a couple of minutes.


On Fri, May 29, 2015 at 9:03 AM, Sergiu Dumitriu
sergiu.dumit...@gmail.com wrote:
 Good work!

 Mike, could you provide these instructions as patches, one for each branch?

 So, given that getting a working build for the 1.7.x branch is actually
 quite easy, we could quickly fix a couple of things and release 1.7.1.
 Does any committer want to take the lead on that?

 On 05/29/2015 08:48 AM, Mike Kienenberger wrote:
 On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger mkien...@gmail.com 
 wrote:
 1.3 and 1.4 won't build without some code changes -- they use enum as
 a variable.

 These were generated parser files.  A find and replace of enum to enmr
 was all that was needed.   Or going back to java 1.3 :)

 Parser modification also seems possible now, although the large number
 of changes between my generated code and the old generated code seems
 to indicate that I'm still not using the same version of javacc that
 the original code was generated from.  1.6 is a close enough match
 that I suspect it uses javacc 3.2.   That probably means 1.5 was
 generated with something older and 1.7 was generated with something
 newer.

 Part of the differences turned out to be code reformatting of the
 generated files.  Velocity 1.5 used javacc 3.1.   1.6 used javacc 3.2.
 Velocity 1.7 used javacc 4.2 but JJTParserState.java file needs to be
 manually reverted manually after running the parser task.   The newly
 generated JJTParserState only changes the file checksum and loses the
 org.apache.velocity.runtime.parser.node.Node import.

 -
 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: Successfully building 1.x branches and regenerating parser files

[Mike Kienenberger]

I have created issues 861 (improve parser documentation) and 862 (fix
parser import generation) to clean up the parser building process.

https://issues.apache.org/jira/browse/VELOCITY-861

https://issues.apache.org/jira/browse/VELOCITY-862

On Fri, May 29, 2015 at 9:33 AM, Mike Kienenberger mkien...@gmail.com wrote:
 I've already created issue 860 and I have already attached individual
 patches for fixing the build scripts in 1.5, 1.6.x, and 1.7.x
 branches.

 https://issues.apache.org/jira/browse/VELOCITY-860.

 Modifying unusable build files to point to the right download
 locations is one thing, but I'm on the fence about whether we should
 change the 1.3.1 or 1.4 java files to make them build on newer
 versions of java.  Using an older version of java or possibly using a
 source  target javac flag leaves them usable as is.   If a person
 really wants to make them work under a newer version of java, it's
 easy to rename the variables, but that would have to be done each time
 the parsing files are regenerated using the older javacc packages.

 I am currently in the process of updating the build instructions for
 the parser, and removing the old build.sh script -- it only adds
 confusion now that the main build script does everything necessary.  I
 should be finished with that in a couple of minutes.


 On Fri, May 29, 2015 at 9:03 AM, Sergiu Dumitriu
 sergiu.dumit...@gmail.com wrote:
 Good work!

 Mike, could you provide these instructions as patches, one for each branch?

 So, given that getting a working build for the 1.7.x branch is actually
 quite easy, we could quickly fix a couple of things and release 1.7.1.
 Does any committer want to take the lead on that?

 On 05/29/2015 08:48 AM, Mike Kienenberger wrote:
 On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger mkien...@gmail.com 
 wrote:
 1.3 and 1.4 won't build without some code changes -- they use enum as
 a variable.

 These were generated parser files.  A find and replace of enum to enmr
 was all that was needed.   Or going back to java 1.3 :)

 Parser modification also seems possible now, although the large number
 of changes between my generated code and the old generated code seems
 to indicate that I'm still not using the same version of javacc that
 the original code was generated from.  1.6 is a close enough match
 that I suspect it uses javacc 3.2.   That probably means 1.5 was
 generated with something older and 1.7 was generated with something
 newer.

 Part of the differences turned out to be code reformatting of the
 generated files.  Velocity 1.5 used javacc 3.1.   1.6 used javacc 3.2.
 Velocity 1.7 used javacc 4.2 but JJTParserState.java file needs to be
 manually reverted manually after running the parser task.   The newly
 generated JJTParserState only changes the file checksum and loses the
 org.apache.velocity.runtime.parser.node.Node import.

 -
 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: Upgraded Commons and Velocity 2.0

[Mike Kienenberger]

On Fri, May 29, 2015 at 10:33 AM, Nathan Bubna nbu...@gmail.com wrote:
 If Mike wants to revive the Ant build for 1.7, i have no problem with that.
 I do remember the JJParserState issue when rebuilding the parser though.
 Always bugged me, but i never saw an easy fix.

My first try at an easy fix failed, but I've got a v2 patch in issue
862 that will work -- I cheated and used the ant replace task to add
the import after the package declaration.

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

Minimum java version for a 1.8 branch?

[Mike Kienenberger]

I think we should also upgrade the minimum java version required for
Velocity if we create a 1.8 branch.

[javac] warning: [options] bootstrap class path not set in
conjunction with -source 1.4
[javac] warning: [options] source value 1.4 is obsolete and will
be removed in a future release
[javac] warning: [options] target value 1.4 is obsolete and will
be removed in a future release
[javac] warning: [options] To suppress warnings about obsolete
options, use -Xlint:-options.

Java 1.5 is probably ok, but honestly, I don't have any systems that
have java 1.5 or 1.6 installed any more, and Oracle Java 1.6 is now
EOL.  I'd suggest we go with Java 1.7, but try to avoid (at least in
the short term) usage new language features.   Officially, support and
release with 1.7 but unofficially let someone recompile it with 1.5?

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

Re: Upgraded Commons and Velocity 2.0

[Mike Kienenberger]

On Fri, May 29, 2015 at 10:57 AM, Frederick N. Brier fnbr...@gmail.com wrote:
 I did a large amount of work last year on the Velocity 1.7 branch, split it
 into a main project and sub projects that integrated with other components,
 updated the packages, switched to slf4j and got it building under Maven.  I
 am using it in an Android project I am trying to finish.  That has stalled
 for the moment as I am on contract.  I posted this on this list and everyone
 was supportive, but they wanted me to look at the 2.0 branch and see if I
 could not lose those updates.  I did not know about the 2.0 codebase.  I
 have not had time to try and merge the changes.  I would be more than happy
 to push my changes to github and have anyone review them and determine if
 the changes I made would be a good restarting point.

I remember reading your message but having no time for velocity when it came up.

I'm definitely interested in upgrading the 1.x dependencies, so if you
push your code to github, I probably remember enough git to isolate
and merge changes related to that.  If nothing else, we can use it as
a reference for future changes.

I am also interested in SLF4J support (sorry, Chris, but if you're
going to propose switching to commons-logging, you might as well go
with SLF4J: http://www.slf4j.org/faq.html#why_new_project) and my long
term goals include getting MyFaces and Cayenne to switch to slf4j.
But it's not a priority.

I'm not interested in maven support, but someone else might be.

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

Re: Upgraded Commons and Velocity 2.0

[Mike Kienenberger]

Yes, I use Velocity 1.3.1 and SLF4J, so I know how to make it all work
together but I have a whole lot of bridges and adaptors installed. :)
I'd prefer that we standardize on SLF4J if we're switching away from
log4j.   It's easier for end-users.

On Fri, May 29, 2015 at 11:28 AM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
 2015-05-29 17:21 GMT+02:00 Mike Kienenberger mkien...@gmail.com:

 I am also interested in SLF4J support (sorry, Chris, but if you're
 going to propose switching to commons-logging, you might as well go
 with SLF4J: http://www.slf4j.org/faq.html#why_new_project) and my long
 term goals include getting MyFaces and Cayenne to switch to slf4j.
 But it's not a priority.


 In theory, Velocity 2.0 has support for SLF4J:
 http://svn.apache.org/repos/asf/velocity/engine/trunk/velocity-engine-slf4j/

 Moreover, remember that you can use jcl-over-slf4j to mimic commons-logging
 while redirecting commons-logging messages to slf4j.

 Antonio

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

Re: Successfully building 1.x branches and regenerating parser files

[Mike Kienenberger]

You only need to regenerate the parser files when there is something
wrong with the grammar or the grammar needs improving.

I did not make it so that each build regenerates the grammar.   ant
parser will regenerate the grammar, creating updated *.java files.
ant jar will build the project.  They remain two separate and
independent commands.

There's a specific regression that happened between 1.3.1 and 1.4 that
I need to fix to use velocity: #settab is no longer working -- only
space is recognized as whitespace between #set and the left
parenthesis.   Jira issue with patch to be created in the near future,
but the bug was mentioned on the mailing list a year ago.

I don't know the answer to the maven question, but I think Will was
going to look at the maven parser in any case.   I suspect that
changing the javacc version could be an issue, though, as it probably
impacts other generated files.   I seem to recall trying to build the
parser with javacc 6 last year and failing miserably, but I haven't
tried recently enough to remember any specific details.

On Fri, May 29, 2015 at 5:33 PM, Frederick N. Brier fnbr...@gmail.com wrote:
 So this whole thread about javacc made me realize I was using the parser
 source files that were checked in and I was not regenerating the parser with
 each build.  I started to look at how to do that and realize that many of
 the files had been modified, modified and copied, and that may be why they
 were just checked in.  It sounds like Mike just set it up so every build is
 now regenerating the parser?  Or was that happening before and I missed it
 when I converted from Ant to Maven?

 Also, I noticed that javacc us up to release 6.1.2 and the associated Maven
 plugin is 2.6.  Is there a problem moving to 6.1.2 and sticking with 4.2?
 Should I change my Maven build to regenerate the parser?  Or is it enough
 that I pushed my code to Github.  Thank you.

 Fred


 On 05/29/2015 06:59 AM, Mike Kienenberger wrote:

 I have created issues 861 (improve parser documentation) and 862 (fix
 parser import generation) to clean up the parser building process.

 https://issues.apache.org/jira/browse/VELOCITY-861

 https://issues.apache.org/jira/browse/VELOCITY-862

 On Fri, May 29, 2015 at 9:33 AM, Mike Kienenberger mkien...@gmail.com
 wrote:

 I've already created issue 860 and I have already attached individual
 patches for fixing the build scripts in 1.5, 1.6.x, and 1.7.x
 branches.

 https://issues.apache.org/jira/browse/VELOCITY-860.

 Modifying unusable build files to point to the right download
 locations is one thing, but I'm on the fence about whether we should
 change the 1.3.1 or 1.4 java files to make them build on newer
 versions of java.  Using an older version of java or possibly using a
 source  target javac flag leaves them usable as is.   If a person
 really wants to make them work under a newer version of java, it's
 easy to rename the variables, but that would have to be done each time
 the parsing files are regenerated using the older javacc packages.

 I am currently in the process of updating the build instructions for
 the parser, and removing the old build.sh script -- it only adds
 confusion now that the main build script does everything necessary.  I
 should be finished with that in a couple of minutes.


 On Fri, May 29, 2015 at 9:03 AM, Sergiu Dumitriu
 sergiu.dumit...@gmail.com wrote:

 Good work!

 Mike, could you provide these instructions as patches, one for each
 branch?

 So, given that getting a working build for the 1.7.x branch is actually
 quite easy, we could quickly fix a couple of things and release 1.7.1.
 Does any committer want to take the lead on that?

 On 05/29/2015 08:48 AM, Mike Kienenberger wrote:

 On Thu, May 28, 2015 at 10:48 PM, Mike Kienenberger
 mkien...@gmail.com wrote:

 1.3 and 1.4 won't build without some code changes -- they use enum as
 a variable.

 These were generated parser files.  A find and replace of enum to enmr
 was all that was needed.   Or going back to java 1.3 :)

 Parser modification also seems possible now, although the large number
 of changes between my generated code and the old generated code seems
 to indicate that I'm still not using the same version of javacc that
 the original code was generated from.  1.6 is a close enough match
 that I suspect it uses javacc 3.2.   That probably means 1.5 was
 generated with something older and 1.7 was generated with something
 newer.

 Part of the differences turned out to be code reformatting of the
 generated files.  Velocity 1.5 used javacc 3.1.   1.6 used javacc 3.2.
 Velocity 1.7 used javacc 4.2 but JJTParserState.java file needs to be
 manually reverted manually after running the parser task.   The newly
 generated JJTParserState only changes the file checksum and loses the
 org.apache.velocity.runtime.parser.node.Node import.

 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org