Re: Versioning
Hi. We should think in term of audience. Yes, git logs are public, everything we do in this project is, but to what audience compared to final releases? And 99% of the users are end-users only interested in releases. The remaining is our internal kitchen business, which is certainly not under the same quality pressure than releases. On this regard, not having sequential release versions looks like a flaw to me, versions are semantically useful to end-users, I don't consider it a purely cosmetic issue, whereas having a doublon in the git logs does, and only for advanced users, and sincerely, who cares? Keeping manual steps minimum is a technical issue which should be solved once we know what we want - managing release candidates should be properly done in the maven-release-plugin, it is not, the manual steps are just here to circumvent this problem. We could certainly do better (but frankly, it's not that complex, it's copy-pasting), and feel free to amend the process. I understand that you went on without taking this versioning constraint into consideration, no harm in that. But since we always had sequential versioning in the history of the project, would it be so hard to continue to enforce it? Claude On 17/04/2024 09:12, Michael Osipov wrote: Am 2024-04-10 um 22:01 schrieb Claude Brisson: Hi team. Can we clarify a little bit the versioning for the future releases? My point of view is quite simple: did the engine 4.2 get released? No. So it should be the next version. If it's not what is intended, I need a detailed explanation, because I really don't understand Michael response: > because that version should not appear more than once on the log: https://github.com/apache/velocity-engine/commits/master/. What do you mean exactly by the fact that a "version" does "appear" on the "log"? None of those terms are clear to me in this context... Claude, the Git log contains the messages from the Maven Release Plugin with that tag name chosen during release time. E.g., "[maven-release-plugin] prepare release 2.4.1" from [1]. Yet another point I'd like to raise is that the should keep manual steps to a minimum. Avoid gaps in the sequence just creates even more friction in the release process. Looking at [2], way too complex. At the end the only viable releases are the source tarball and what people will download from Maven Central. Michael [1] https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#scmReleaseCommitComment [2] https://velocity.apache.org/release-process.html - 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
Versioning
Hi team. Can we clarify a little bit the versioning for the future releases? My point of view is quite simple: did the engine 4.2 get released? No. So it should be the next version. If it's not what is intended, I need a detailed explanation, because I really don't understand Michael response: > because that version should not appear more than once on the log: https://github.com/apache/velocity-engine/commits/master/. What do you mean exactly by the fact that a "version" does "appear" on the "log"? None of those terms are clear to me in this context... Regards, Claude - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-206) Upgrade to Velocity Engine 2.4.2
[ https://issues.apache.org/jira/browse/VELTOOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823138#comment-17823138 ] Claude Brisson commented on VELTOOLS-206: - 2.4.2 ?! So you're not comming back to 2.4? I don't understand why. Even if a tag is public, you can delete it. > Upgrade to Velocity Engine 2.4.2 > > > Key: VELTOOLS-206 > URL: https://issues.apache.org/jira/browse/VELTOOLS-206 > Project: Velocity Tools > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Engine version 2.4.1
I use this one [1] sans the part which does not apply to Velocity TLP to comply with ASF release requirements. If there is a documentation for the Velocity project which does not have more manual steps compared to the [1], I will happily do it, but I don't want to waste my time for unnecessary juggling. I rather invest it in making the code base better. [1] works very well for the entire Maven ecosystem and is followed by Maven devs, I don't see why I cannot apply to ther ASF Java-centric TLPs. Please note that the entire Maven Site Plugin ecosystem relies on Velocity Engine and Tools, so this is why I want to move this one forward and in greater for the entire OSS community. Michael [1]https://maven.apache.org/developers/release/maven-project-release-procedure.html We have our release process page [2]. [2] https://velocity.apache.org/release-process.html
Re: [VOTE] Release Velocity Engine version 2.4.1
On 19/02/2024 21:34, Michael Osipov wrote: On 2024/02/19 20:25:45 Claude Brisson wrote: Version numbers are advertized and are supposed to be coherent. We don't care that the tags are public, they are not advertized. I didn't say that you had to reuse the tag. The tag can be named 2.4-RC2. You don't have to rename anything, or did I miss something? I cannot follow. What am I supported to do with 2.4-RC2? I cannot supply this to Maven Release Plugin otherwise it will bein the POM and in the repo. This is already on master and shouldn't appear again: https://github.com/apache/velocity-engine/commit/5d9e48ca0f1776300f1cf07199eb79c34dbe9cb7 Git tag and version in POM have to be consistent. They are supposed to be consistent, that's why the tag you put to call the vote should be in the form 2.4-RCx. Otherwise, there would be a hole in the versioning each time there is a failed vote. Because the RC tag was named 2.4, you cannot reuse it, so let's use another tag, it's not a big deal. I don't understand the point with the maven plugin. The plugin -or its use- has to adapt to the chosen versioning, not the opposite. I don't see how this can be achieved. I'm sure that there's a way of doing it. If not, you can still erase the 2.4 tag, after all. I mean, releasing the 2.4.1 *without* having released the 2.4 is... weird. There must be a way. Moreover, that version needs to land as source release zip on ASF dist area. The zip content cannot be x-RCy. On that, we agree. The RC life span *is* the vote. Claude I guess I miss here something as well. Michael - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Engine version 2.4.1
Version numbers are advertized and are supposed to be coherent. We don't care that the tags are public, they are not advertized. I didn't say that you had to reuse the tag. The tag can be named 2.4-RC2. You don't have to rename anything, or did I miss something? Claude On 18/02/2024 23:06, Michael Osipov wrote: There are several issues with reusing tags and why this is wrong: * Versions are cheap * As soon as a tag is pushed it is replicated (public), changing the tag would break public * Git log would show the same version twice on master: does not make sense * Building the two tags with the same version would yield a different result * Fiddling in the repo to rename something is unnecessary manual work for me * Failed version is marked as archived, visible that it didn't make it It Maven land we simply burn version because it is honest and straight forward. Doing additional manual steps for tens of components does not really work. Michael On 2024/02/18 15:28:11 Claude Brisson wrote: The previous "2.4" was just a PR, so why would we jump to 2.4.1 for the version ? It's a minor annoyance if you cannot reuse the tag 2.4, just name the tag 2.4-final or something like that, no? It's more annoying if there is a phantom 2.4 version number which has not been release, IMO. On 18/02/2024 13:45, Michael Osipov wrote: Hi, Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310104=12354231 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1043/ https://repository.apache.org/content/repositories/orgapachevelocity-1043/org/apache/velocity/velocity-engine-parent/2.4.1/velocity-engine-parent-2.4.1-source-release.zip Source release checksum(s): velocity-engine-parent-2.4.1-source-release.zip sha512: 140854cf8e2a1f315b954d8be8c56f0087a13ec647065ecdea3594d2cb0099414fede608a2a9392f15beb04e6fb89b220710d0032b9bd734113e6bf578550187 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - 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 Engine version 2.4.1
The previous "2.4" was just a PR, so why would we jump to 2.4.1 for the version ? It's a minor annoyance if you cannot reuse the tag 2.4, just name the tag 2.4-final or something like that, no? It's more annoying if there is a phantom 2.4 version number which has not been release, IMO. On 18/02/2024 13:45, Michael Osipov wrote: Hi, Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310104=12354231 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1043/ https://repository.apache.org/content/repositories/orgapachevelocity-1043/org/apache/velocity/velocity-engine-parent/2.4.1/velocity-engine-parent-2.4.1-source-release.zip Source release checksum(s): velocity-engine-parent-2.4.1-source-release.zip sha512: 140854cf8e2a1f315b954d8be8c56f0087a13ec647065ecdea3594d2cb0099414fede608a2a9392f15beb04e6fb89b220710d0032b9bd734113e6bf578550187 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Tools version 3.2
About the tools, I think we should drop the jsp module. Nobody is maintaining it. On 14/02/2024 10:26, Claude Brisson wrote: Yes, thanks :-) On 13/02/2024 20:00, Michael Osipov wrote: On 2024/02/13 17:39:38 Claude Brisson wrote: Maybe it's nitpicking, but having the users being able to build without errors is a precaution which is worth repackaging an engine RC, since we're at it... no? I don't consider this as nitpicking, but you need to consider the failure reason as well. The actual code works as intended. Your points are valid. Do you want me to drop, remove the test and re-roll the release? M - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Tools version 3.2
Yes, thanks :-) On 13/02/2024 20:00, Michael Osipov wrote: On 2024/02/13 17:39:38 Claude Brisson wrote: Maybe it's nitpicking, but having the users being able to build without errors is a precaution which is worth repackaging an engine RC, since we're at it... no? I don't consider this as nitpicking, but you need to consider the failure reason as well. The actual code works as intended. Your points are valid. Do you want me to drop, remove the test and re-roll the release? M - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Tools version 3.2
Maybe it's nitpicking, but having the users being able to build without errors is a precaution which is worth repackaging an engine RC, since we're at it... no? On 13/02/2024 18:09, Michael Osipov wrote: On 2024/02/13 15:25:42 Claude Brisson wrote: Since I could not build the engine RC, I cannot test the tools RC without tweaking the poms. As a followup to your comments I found another issue for tests: https://github.com/apache/velocity-tools/pull/17 Though, it is not a blocker because it does not affect runtime behavior, just testing. - 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 Tools version 3.2
Since I could not build the engine RC, I cannot test the tools RC without tweaking the poms. Usually, I first release the engine then the tools. Also, I think it is a good practice to name RC tags 2.4-rc1, etc. and to only tag the release with 2.4. Best, Claude On 13/02/2024 14:35, Michael Osipov wrote: Guys, last day for votes. Please have a look. - 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 Engine version 2.4
Ooops, changing my vote to -1, I have a problem building: [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.012 s <<< FAILURE! -- in org.apache.velocity.test.issues.VelTools66TestCase [ERROR] org.apache.velocity.test.issues.VelTools66TestCase.testVelTools66 -- Time elapsed: 0.011 s <<< ERROR! java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release at java.base/java.lang.System.setSecurityManager(System.java:416) at org.apache.velocity.test.issues.VelTools66TestCase.setUp(VelTools66TestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:140) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:130) at junit.framework.TestSuite.runTest(TestSuite.java:241) at junit.framework.TestSuite.run(TestSuite.java:236) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495) $ java -version openjdk version "18.0.2-ea" 2022-07-19 OpenJDK Runtime Environment (build 18.0.2-ea+9-Ubuntu-2ubuntu1) OpenJDK 64-Bit Server VM (build 18.0.2-ea+9-Ubuntu-2ubuntu1, mixed mode, sharing) On 13/02/2024 16:19, Claude Brisson wrote: It's too bad I'm so busy those days to incorporate a few more issues. But +1 anyway, that's already something. Claude On 13/02/2024 14:35, Michael Osipov wrote: Guys, last day for votes. Please have a look. - 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 Engine version 2.4
It's too bad I'm so busy those days to incorporate a few more issues. But +1 anyway, that's already something. Claude On 13/02/2024 14:35, Michael Osipov wrote: Guys, last day for votes. Please have a look. - 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 version 6
+1 On 05/02/2024 06:55, Nathan Bubna wrote: +1 On Sat, Feb 3, 2024 at 10:07 AM Michael Osipov wrote: Hi, Changelog: * Upgrade to Apache Parent 31 * Explicitly require Maven 3.2.5+ at build time Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1040/ https://repository.apache.org/content/repositories/orgapachevelocity-1040/org/apache/velocity/velocity-master/6/velocity-master-6-source-release.zip Source release checksum(s): velocity-master-6-source-release.zip sha512: d95b652d327b9efc17f8ef0959f15c71a1fcef79c2497d1ea5713a466d1e7035a9e4132ea48f2db8f692672c831ba8430c1ba1164aa5e0faeb24b8645bcc2bcf Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-970) velocity-engine-core contains commons-io Maven descriptor
[ https://issues.apache.org/jira/browse/VELOCITY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805706#comment-17805706 ] Claude Brisson commented on VELOCITY-970: - That's not strange, that's an effect of the shading: one pom is to compile it, one to use it at runtime. > velocity-engine-core contains commons-io Maven descriptor > - > > Key: VELOCITY-970 > URL: https://issues.apache.org/jira/browse/VELOCITY-970 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.3 >Reporter: Thomas Mortagne >Priority: Major > > commons-io is embedded in velocity-engine-core, which is OK from Java point > of view since its package is renamed (not causing any dependency problems). > The problem is that it contains the commons-io Maven descriptors at the > standard location (/META-INF/maven/commons-io/commons-io/), which is a > problem when you analyze JAR files to find what's in it because it ends up > being identified as a JAR exposing commons-io (which is not the case since > it's weaved). > Honestly, it feels very strange to embed commons-io in the first place given > that commons-lang for example is a transitive dependency, so I feel like the > simplest would just be to remove all the plumbing to embed and weave > commons-io and simply keep it as a regular transitive dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-969) Lower scripts parser performance after update from 1.6 to 2.3 velocity version
[ https://issues.apache.org/jira/browse/VELOCITY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794167#comment-17794167 ] Claude Brisson commented on VELOCITY-969: - We can potentially do something if we can reproduce the problem, or preferably if you can help us track down the origin of the regression by doing some profiling. > Lower scripts parser performance after update from 1.6 to 2.3 velocity version > -- > > Key: VELOCITY-969 > URL: https://issues.apache.org/jira/browse/VELOCITY-969 > Project: Velocity > Issue Type: Bug >Reporter: Magdalena Karpierz >Priority: Critical > > Hello Team, > > We have problems after update velocity 1.6.3 to 2.3 version with parsing > performance of the scripts which include many macros inside and overall > lenght of the script is about 3000 lines. > Performance execution of this kind of scripts decreased 10 times, example > script execution in velocity1 took: 1sec. and in velocity2: 6 to 10 seconds. > > Did You observe such performance issues? > Can You suggest us a potential solution for this problem? > > I prioritized this ticket as a critical, because our customers saw this > immediately and it blocks some further activities. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE][RESULT] Release Velocity Master version 5
Three binding +1, we shall release velocity-master pom version 5. On 31/03/2023 11:38, Michael Osipov wrote: Claude, the vote is over. Please proceed. - 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] (VELOCITY-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-963. --- Assignee: Claude Brisson Resolution: Won't Fix > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus > Assignee: Claude Brisson >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705088#comment-17705088 ] Claude Brisson commented on VELOCITY-963: - Point #3 is already documented, as stated by the reporter. Points #1 and #4 concern code entry points that should only be internal (too bad they're not) ; and the fix isn't difficult. For point #2: > VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. Because of type erasure, we cannot add a deprecated constructor taking a Map. So I don't see an easy fix, other than fixing the calling code. Yes, that's legitimate with the major version change. > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-964:
Affects Version/s: 2.3
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.3
> Reporter: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-964:
Component/s: Engine
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
> Reporter: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELOCITY-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reassigned VELOCITY-964:
---
Assignee: Claude Brisson
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.3
> Reporter: Claude Brisson
> Assignee: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-964) Allow formal notation for block macros
[
https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-964:
Description:
The syntax #@\{test} is not functional.
> Allow formal notation for block macros
> --
>
> Key: VELOCITY-964
> URL: https://issues.apache.org/jira/browse/VELOCITY-964
> Project: Velocity
> Issue Type: Bug
> Reporter: Claude Brisson
>Priority: Minor
>
> The syntax #@\{test} is not functional.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-964) Allow formal notation for block macros
[ https://issues.apache.org/jira/browse/VELOCITY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-964: Priority: Minor (was: Major) > Allow formal notation for block macros > -- > > Key: VELOCITY-964 > URL: https://issues.apache.org/jira/browse/VELOCITY-964 > Project: Velocity > Issue Type: Bug > Reporter: Claude Brisson >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-964) Allow formal notation for block macros
Claude Brisson created VELOCITY-964: --- Summary: Allow formal notation for block macros Key: VELOCITY-964 URL: https://issues.apache.org/jira/browse/VELOCITY-964 Project: Velocity Issue Type: Bug Reporter: Claude Brisson -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705081#comment-17705081
]
Claude Brisson commented on VELOCITY-940:
-
PS: I open another issue for #@\{test} and #\{@test} (to be consistent, it
should be #@\{test}).
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
> Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-940.
-
Fix Version/s: 2.4
Assignee: Claude Brisson
Resolution: Fixed
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
> Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.4
>
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-940) bodyContent in nested macros called without @ should be unset
[
https://issues.apache.org/jira/browse/VELOCITY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705080#comment-17705080
]
Claude Brisson commented on VELOCITY-940:
-
Velocimacros do support recursion. But there was a specific bug whenever using
a non-block call inside a block. Fixed in 2.4.
> Probably related, if you call a #@macro from inside another #@macro, the
> $bodyContent gets trashed, as in it doesn't seem to get restored when the
> inner macro finishes.
Not reproduced. But one thing to note: if you alter the content of $bodyContent
with a #set directive, the initial value won't be restored. This is by design.
> bodyContent in nested macros called without @ should be unset
> -
>
> Key: VELOCITY-940
> URL: https://issues.apache.org/jira/browse/VELOCITY-940
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.3
>Reporter: Willow Nice
>Priority: Minor
>
> Hi! First ever maybe bug report (pls be gentle).
>
> {{#macro(test $label)Something $!label $!bodyContent#\{end}}}
> {{#@test('First')}}{{#test('Second')}}{{#end}}
>
> ends up a recurring mess because $bodyContent seems to be still defined when
> calling the inner macro without a block. I propose (perleeze) that it should
> always be unset when calling a macro without a block. It's fine if you always
> call with @ and supply an empty block, or unset it manually before the second
> call
> p.s.
> #@\{test} or #\{@test} doesn't work either
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705042#comment-17705042 ] Claude Brisson commented on VELOCITY-963: - IMO those are only points to document in the migration guide. Restoring an old method with a workaround inside is prone to side effects, now that the parser is supposed to know the template object. But thanks for the report! > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-963) Incompatible API changes in 2.x
[ https://issues.apache.org/jira/browse/VELOCITY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-963: Component/s: Documentation (was: Engine) > Incompatible API changes in 2.x > --- > > Key: VELOCITY-963 > URL: https://issues.apache.org/jira/browse/VELOCITY-963 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 2.0, 2.1, 2.2, 2.3 >Reporter: Éamonn McManus >Priority: Minor > > I recently tried porting a large amount of Velocity client code from 1.7 to > 2.3 and discovered a number of incompatible API changes. Some of these were > probably unavoidable but at least one could be fixed to ease this kind of > migration. > * The three RuntimeInstance.parse methods from 1.7 were replaced by a single > RuntimeInstance.parse(Reader, Template) method. I found that I could work > around this by changing this: > SimpleNode node = runtimeInstance.parse(reader, resourceName); > to this: > Template template = new Template(); > template.setName(resourceName); > SimpleNode node = runtimeInstance.parse(reader, template); > But it would be convenient for people migrating if the old overloads were > restored. (This might not be the best way to parse a template, but it was > certainly quite widely used in the code I was porting.) > * VelocityContext(Map) becomes VelocityContext(Map). Some of > the code was passing a Map or a Map. That would > work if the argument type were Map, but I don't think that would > be correct since I believe the Map can be updated by #set directives. So > perhaps document this more explicitly. > * This abstract method in ResourceLoader > InputStream getResourceStream(String source) > becomes > Reader getResourceReader(String source, String encoding) > I'm not sure there would have been a good way to allow subclasses of > ResourceLoader to continue to work without change, and this change _is_ > documented in the [migration > guide|https://velocity.apache.org/engine/2.0/upgrading.html#behavior-api-changes] > so there's probably nothing further to do here. > * Nearly all the methods in StringUtils have been deleted, and that's not > mentioned in the migration guide. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Master version 5
+1 Claude On 25/03/2023 12:59, Claude Brisson wrote: Hello. Please vote for the release of the velocity-master release 5. Changes: + upgraded parent apache pom to version 29 + upgraded maven plugins to latest version + list Will Glass-Husain as Emeritus (I still wonder why we list the staff in the master pom by the way) Staging repository : https://repository.apache.org/content/repositories/orgapachevelocity-1039/ https://repository.apache.org/content/repositories/orgapachevelocity-1039/org/apache/velocity/velocity-master/5/velocity-master-5-source-release.zip Source release checksum(s): velocity-master-5-source-release.zip sha512: 853d13c9cbe0dc7f597538420baa07ad27492a2a4a870e4095c93fd7d573a986ddcfd3d96923c102e3fd03b16df520e7e8471e2805c1de9aa93886994477926d Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Claude - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[VOTE] Release Velocity Master version 5
Hello. Please vote for the release of the velocity-master release 5. Changes: + upgraded parent apache pom to version 29 + upgraded maven plugins to latest version + list Will Glass-Husain as Emeritus (I still wonder why we list the staff in the master pom by the way) Staging repository : https://repository.apache.org/content/repositories/orgapachevelocity-1039/ https://repository.apache.org/content/repositories/orgapachevelocity-1039/org/apache/velocity/velocity-master/5/velocity-master-5-source-release.zip Source release checksum(s): velocity-master-5-source-release.zip sha512: 853d13c9cbe0dc7f597538420baa07ad27492a2a4a870e4095c93fd7d573a986ddcfd3d96923c102e3fd03b16df520e7e8471e2805c1de9aa93886994477926d Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Claude - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Releasing Velocity Tools 3.2
On 22/03/2023 16:25, Michael Osipov wrote: I wouldn't waste a single minute for that unless there is a strong reason and user complaints. Only the servlet views and request/session-related stuff is affected. The engine is not affected. But the tools are (with the view-tools). We should do it because not doing it impacts the migration of all dependent projects (even if there are some dirty hacks around)... Claude - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Releasing Velocity Tools 3.2
And it should be better to first push out a release of the engine (there is at least one CVE on the jdom dependency). Ah, and follow the movement and make the javax => jakarta migration, shouldn't we? Then, how? Does it imply a major version change? If yes, it means two releases per module... Claude PS - read somewhere on twitter: "I wish to know how many man-years the whole #Java developers community wasted on the idiotic javax -> jakarta migration so far, and more important I wish there could be a way to make @Oracle to pay for it." On 14/03/2023 11:06, Michael Osipov wrote: Am 2023-03-14 um 01:15 schrieb Claude Brisson: There is some work on the open issues... I'll try to get some done. Merci, Claude ! - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Releasing Velocity Tools 3.2
There is some work on the open issues... I'll try to get some done. On 12/03/2023 19:09, Michael Osipov wrote: Folks, I'd like to integrate Velocity Tools 3.2 into next release of Maven Doxia Sitetools, thus Maven Site Plugin. Is anyone willing to to do the 3.2 release? Michael - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[ https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636011#comment-17636011 ] Claude Brisson commented on VELTOOLS-184: - There may be broken Json parsers in the wild, but that's not a reason for us to escape things that don't need to be. > EscapeTool: add a json method, or a javascript method with a second parameter > - > > Key: VELTOOLS-184 > URL: https://issues.apache.org/jira/browse/VELTOOLS-184 > Project: Velocity Tools > Issue Type: Improvement > Components: GenericTools >Affects Versions: 2.x > Environment: any >Reporter: Maurice Perry >Priority: Minor > Labels: EscapeTool, escape, javascript, json > > The string returned by EscapeTool.javascript() method is not alway compliant > with the JSON syntax. For instance, when the input string contains an > apostrophe ', a backslash is inserted before it because there is no way for > the method to know if the string is enclosed with single or double quotes. > This is not compliant with the JSON syntax, and some JSON parsers will reject > the string. > There may be other differences between javascript and JSON strings, but this > is the one I encountered, and I had to use a workaround. > This issue can be solved either with a JSON method, or with a second > javascript method with a second parameter indicating the type of quote used. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-960.
-
Fix Version/s: 2.3
Assignee: Claude Brisson
Resolution: Fixed
The fix has been commited to the site sources and to the production branch.
It's not yet visible but should be soon (or it's a problem and we'll contact
infra).
No more mention of any "dash".
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Assignee: Claude Brisson
>Priority: Major
> Labels: doc
> Fix For: 2.3
>
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-960) Documentation inconsistency for use of hypens on identifiers
[
https://issues.apache.org/jira/browse/VELOCITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631027#comment-17631027
]
Claude Brisson commented on VELOCITY-960:
-
The "parser.allows.dash.identifiers" mention is a reference to a long
disappeared name for this property.
The property name is "parser.allow_hyphen_in_identifiers", and it's a hyphen,
we're all good.
[~calvernaz] Thanks for catching this documentation glinche!
> Documentation inconsistency for use of hypens on identifiers
> -
>
> Key: VELOCITY-960
> URL: https://issues.apache.org/jira/browse/VELOCITY-960
> Project: Velocity
> Issue Type: Bug
>Reporter: Cesar Alvernaz
>Priority: Major
> Labels: doc
>
> Regarding the use of hypens on identifiers, the documentation doesn't look
> consistent. Which one is recommended?
> [Here|https://velocity.apache.org/engine/2.3/configuration.html] states the
> following:
> *{{parser.allow_hyphen_in_identifiers = false}}*
> {quote}This is a backward compatibility option, false by default, which
> allows the '{*}{{-}}{*}' character inside variable identifiers (available
> since 2.1). If enabled, be warned that you will have to surround the
> mathematical minus sign with spaces for it to be correctly interpreted.
> {quote}
>
> But [here|https://velocity.apache.org/engine/2.3/vtl-reference.html], the
> configuration is different:
> {quote}{{If the *parser.allows.dash.identifiers*}} configuration value is set
> to true, then the *-* dash is also allowed in identifiers (and must be
> surrounded by spaces to be interpreted as an arithmetic minus operator).}}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Please fix DOAP for Anakia
Ah, it's in the velocity-site git repo. Fixed there. On 07/08/2022 15:45, Claude Brisson wrote: Hi Sebb. This Velocity subproject has been archived eons ago, it seems like I can even not push any change to its svn repository (Velocity since migrated to git, its svn repository was frozen, and archived subprojects seem frozen too even if they didn't migrate). Regards, Claude On 05/08/2022 16:52, sebb wrote: https://issues.apache.org/jira/browse/ANAKIA-8 has been outstanding for ages; it is a trivial change. Thanks. - 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: Please fix DOAP for Anakia
Hi Sebb. This Velocity subproject has been archived eons ago, it seems like I can even not push any change to its svn repository (Velocity since migrated to git, its svn repository was frozen, and archived subprojects seem frozen too even if they didn't migrate). Regards, Claude On 05/08/2022 16:52, sebb wrote: https://issues.apache.org/jira/browse/ANAKIA-8 has been outstanding for ages; it is a trivial change. Thanks. - 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] (VELTOOLS-195) ConversionTool is deprecated, but no alternative for toBoolean*() provided
[
https://issues.apache.org/jira/browse/VELTOOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELTOOLS-195.
-
Fix Version/s: 3.2
Assignee: Claude Brisson
Resolution: Fixed
Fixed by commit 79842528.
toBoolean() belongs to the NumberTool. Until evidence to the contrary, booleans
*are* numbers.
> ConversionTool is deprecated, but no alternative for toBoolean*() provided
> --
>
> Key: VELTOOLS-195
> URL: https://issues.apache.org/jira/browse/VELTOOLS-195
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
>Reporter: Michael Osipov
> Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.2
>
>
> The {{ConversionTool}} has been deprecated with multiple alternatives, but
> none for {{boolean}}. Thus, relying on {{toBoolean()}} will fail in the
> future. Provide a sane migration path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-959) Ease subclassing of #parse and #include directives
[ https://issues.apache.org/jira/browse/VELOCITY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-959. - Fix Version/s: 2.4 Resolution: Fixed Done with commit 28c97b43 > Ease subclassing of #parse and #include directives > -- > > Key: VELOCITY-959 > URL: https://issues.apache.org/jira/browse/VELOCITY-959 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 > Reporter: Claude Brisson > Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > The #include directive should expose a protected getResource() method and the > #parse directive a protected getTemplate() method so that it is easier to > customize their behavior in a user defined directive inheriting from them. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-959) Ease subclassing of #parse and #include directives
Claude Brisson created VELOCITY-959: --- Summary: Ease subclassing of #parse and #include directives Key: VELOCITY-959 URL: https://issues.apache.org/jira/browse/VELOCITY-959 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 2.3 Reporter: Claude Brisson Assignee: Claude Brisson The #include directive should expose a protected getResource() method and the #parse directive a protected getTemplate() method so that it is easier to customize their behavior in a user defined directive inheriting from them. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-958) Template should be cloneable
[ https://issues.apache.org/jira/browse/VELOCITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-958. - Fix Version/s: 2.4 Resolution: Fixed Added in commit 051f20a8 > Template should be cloneable > > > Key: VELOCITY-958 > URL: https://issues.apache.org/jira/browse/VELOCITY-958 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 2.3 > Reporter: Claude Brisson > Assignee: Claude Brisson >Priority: Minor > Fix For: 2.4 > > > Templates should be cloneable, the clone() method returning a template with a > deep clone of the AST tree. > It allows for dynamic transformations of the AST tree which don't affect the > original template. > One use case is the translation of ASTText nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-958) Template should be cloneable
Claude Brisson created VELOCITY-958: --- Summary: Template should be cloneable Key: VELOCITY-958 URL: https://issues.apache.org/jira/browse/VELOCITY-958 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 2.3 Reporter: Claude Brisson Assignee: Claude Brisson Templates should be cloneable, the clone() method returning a template with a deep clone of the AST tree. It allows for dynamic transformations of the AST tree which don't affect the original template. One use case is the translation of ASTText nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELTOOLS-192) EasyFactoryConfiguration.addDefaultTools() method overwrite previously added tools
[ https://issues.apache.org/jira/browse/VELTOOLS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELTOOLS-192. - Fix Version/s: 3.2 Resolution: Fixed Fixed by commit 994c555d. > EasyFactoryConfiguration.addDefaultTools() method overwrite previously added > tools > -- > > Key: VELTOOLS-192 > URL: https://issues.apache.org/jira/browse/VELTOOLS-192 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools >Affects Versions: 3.1 > Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 3.2 > > > The EasyFactoryConfiguration.addDefaultTools() method will overwrite all > custom tools previously added (for instance with the tools(...) method). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELTOOLS-193) XmlTool not accepting comments
[ https://issues.apache.org/jira/browse/VELTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELTOOLS-193. - Fix Version/s: 3.2 Resolution: Fixed Fixed by commit d5ecd327 > XmlTool not accepting comments > -- > > Key: VELTOOLS-193 > URL: https://issues.apache.org/jira/browse/VELTOOLS-193 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools >Affects Versions: 3.1 > Reporter: Claude Brisson > Assignee: Claude Brisson >Priority: Major > Fix For: 3.2 > > > XML documents or fragments containing XML comments cannot be parsed by > XmlTool. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-194) XmlTool getName()/getNodeName() logic should be the same for getPath()/getNodePath()
[
https://issues.apache.org/jira/browse/VELTOOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464258#comment-17464258
]
Claude Brisson commented on VELTOOLS-194:
-
First step (deprecation of getPath()) pushed to master, see 7c182b10.
> XmlTool getName()/getNodeName() logic should be the same for
> getPath()/getNodePath()
>
>
> Key: VELTOOLS-194
> URL: https://issues.apache.org/jira/browse/VELTOOLS-194
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 3.1
> Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
>
> In XmlTool, the method getName() first checks get("name") before calling
> getNodeName().
> The "path" property should follow the same logic. getPath() should be
> deprecated in favor of getNodePath() so that the new behavior is valid in the
> next major release.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-194) XmlTool getName()/getNodeName() logic should be the same for getPath()/getNodePath()
Claude Brisson created VELTOOLS-194:
---
Summary: XmlTool getName()/getNodeName() logic should be the same
for getPath()/getNodePath()
Key: VELTOOLS-194
URL: https://issues.apache.org/jira/browse/VELTOOLS-194
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 3.1
Reporter: Claude Brisson
Assignee: Claude Brisson
In XmlTool, the method getName() first checks get("name") before calling
getNodeName().
The "path" property should follow the same logic. getPath() should be
deprecated in favor of getNodePath() so that the new behavior is valid in the
next major release.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-193) XmlTool not accepting comments
Claude Brisson created VELTOOLS-193: --- Summary: XmlTool not accepting comments Key: VELTOOLS-193 URL: https://issues.apache.org/jira/browse/VELTOOLS-193 Project: Velocity Tools Issue Type: Bug Components: GenericTools Affects Versions: 3.1 Reporter: Claude Brisson Assignee: Claude Brisson XML documents or fragments containing XML comments cannot be parsed by XmlTool. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-187) Upgrading to beanutils 1.9.4 breaks tools "class" attribute
[ https://issues.apache.org/jira/browse/VELTOOLS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELTOOLS-187. --- > Upgrading to beanutils 1.9.4 breaks tools "class" attribute > --- > > Key: VELTOOLS-187 > URL: https://issues.apache.org/jira/browse/VELTOOLS-187 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools, VelocityView >Affects Versions: 3.0 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 3.1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-185) Upgrade Codehaus Cargo version
[ https://issues.apache.org/jira/browse/VELTOOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELTOOLS-185. --- > Upgrade Codehaus Cargo version > -- > > Key: VELTOOLS-185 > URL: https://issues.apache.org/jira/browse/VELTOOLS-185 > Project: Velocity Tools > Issue Type: Improvement >Reporter: S. Ali Tokmen > Assignee: Claude Brisson >Priority: Minor > Fix For: 3.1 > > Attachments: update-codehaus-cargo-version.patch > > > Codehaus Cargo has, since the version currently in use in the Velocity tools, > accumulated many interesting fixes and improvements, moreover had important > adaptations as [Maven and many other repositories switched to HTTPS-only > since mid January > 2020|https://www.alphabot.com/security/blog/2020/java/Your-Java-builds-might-break-starting-January-13th.html]. > Attached is a patch to upgrade to the latest version. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-192) EasyFactoryConfiguration.addDefaultTools() method overwrite previously added tools
Claude Brisson created VELTOOLS-192: --- Summary: EasyFactoryConfiguration.addDefaultTools() method overwrite previously added tools Key: VELTOOLS-192 URL: https://issues.apache.org/jira/browse/VELTOOLS-192 Project: Velocity Tools Issue Type: Bug Components: GenericTools Affects Versions: 3.1 Reporter: Claude Brisson Assignee: Claude Brisson The EasyFactoryConfiguration.addDefaultTools() method will overwrite all custom tools previously added (for instance with the tools(...) method). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-948) Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than java.util.ArrayList
[
https://issues.apache.org/jira/browse/VELOCITY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417332#comment-17417332
]
Claude Brisson commented on VELOCITY-948:
-
We could add an immutable `IntegerRange.toList()` method for such use cases.
> Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than
> java.util.ArrayList
>
>
> Key: VELOCITY-948
> URL: https://issues.apache.org/jira/browse/VELOCITY-948
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Tom White
>Priority: Minor
>
> Hello!
> I am having issues upgrading from 2.0 to 2.1 with existing templates. The
> minimal below example illustrates the change in behaviour:
> {code:java}
>
>
> #set ($example= [0..50])
> ${example.class.name}
> #set ($example[10] = 500)
>
>
> {code}
>
> With 2.0:
> this prints:
> java.util.ArrayList
> and throws no errors.
>
> With 2.1:
> this prints:
> org.apache.velocity.runtime.parser.node.ASTIntegerRange$IntegerRange
> and throws an UnsupportedMethodException at the set line.
>
> I have tried all kinds of config variables from the docs in a unit test.
> The 2.1 documentation states:
> * The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
> {{java.util.ArrayList}} objects when placed in the context or passed to
> methods. Therefore, your methods that are designed to accept arrays created
> in the template should be written with this in mind.
> [https://velocity.apache.org/engine/2.1/developer-guide.html]
>
>
--
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-948) Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than java.util.ArrayList
[
https://issues.apache.org/jira/browse/VELOCITY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413489#comment-17413489
]
Claude Brisson commented on VELOCITY-948:
-
I think it's the doc which should be updated, rather than the code. The change
comes from [VELOCITY-886|https://issues.apache.org/jira/browse/VELOCITY-886].
Updating values inside a range seems a rather exotic use case, no?
> Number ranges created as ASTIntegerRange$IntegerRange in 2.1 rather than
> java.util.ArrayList
>
>
> Key: VELOCITY-948
> URL: https://issues.apache.org/jira/browse/VELOCITY-948
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Tom White
>Priority: Minor
>
> Hello!
> I am having issues upgrading from 2.0 to 2.1 with existing templates. The
> minimal below example illustrates the change in behaviour:
> {code:java}
>
>
> #set ($example= [0..50])
> ${example.class.name}
> #set ($example[10] = 500)
>
>
> {code}
>
> With 2.0:
> this prints:
> java.util.ArrayList
> and throws no errors.
>
> With 2.1:
> this prints:
> org.apache.velocity.runtime.parser.node.ASTIntegerRange$IntegerRange
> and throws an UnsupportedMethodException at the set line.
>
> I have tried all kinds of config variables from the docs in a unit test.
> The 2.1 documentation states:
> * The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
> {{java.util.ArrayList}} objects when placed in the context or passed to
> methods. Therefore, your methods that are designed to accept arrays created
> in the template should be written with this in mind.
> [https://velocity.apache.org/engine/2.1/developer-guide.html]
>
>
--
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: Typo in engine/2.0/upgrading.html
Thanks for the repport. Fixed. On 2021-04-15 16 h 03, Marnix Bindels wrote: Hi all, If you find the time, you might want to correct a typo in https://velocity.apache.org/engine/2.0/upgrading.html#vtl-changes where the configuration key space.gobbling is missing the l-character. (I suppose that raising a JIRA issue for matters like this, is not the way to go) Thank you, Marnix P.S. If I missed the existence of a separate web or documentation list, please give me directions. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: 1.7.x backport for [SecureUberspector should block methods on ClassLoader and subclasses]
If I go to this page: https://wiki.shibboleth.net/confluence/display/OS30/Home the first thing I see is the not at the top which states: "The OpenSAML 3 software has reached its End of Life and is no longer supported. This space is available for historical purposes only." So why bother patching Velocity 1.7 since the transitive dependency you refer to has reached end of life? On 2021-03-23 05 h 02, Cesar Hernandez wrote: Hi all, I opened https://issues.apache.org/jira/browse/VELOCITY-941 along with the Pull Request https://github.com/apache/velocity-engine/pull/21 to accomplish the backport of the patch applied to master via https://issues.apache.org/jira/browse/VELOCITY-931 Hope the backport makes sense since there is still transitive dependencies from the 1.7 release [1] [1] https://issues.apache.org/jira/browse/WSS-683 https://github.com/apache/velocity-engine/pull/16#issuecomment-799180202 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Resigning from Apache Velocity PMC
Thanks for all, Will. On 2021-03-11 23 h 03, Nathan Bubna wrote: Agreed. Thanks for your long work here, Will. If you're ever in Portland, drop me a line and i'll buy you a drink. :) On Thu, Mar 11, 2021 at 12:11 PM Henning Schmiedehausen < henn...@schmiedehausen.org> wrote: Will, Thank you so much for your time and the part of the journey that we walked together. I hope we still see you around here from time to time. Looking forward to going back to in-person conferences as well, when this is all done, we should get together for beers again. -h On Wed, Mar 10, 2021 at 9:07 PM Will Glass-Husain wrote: Dear Team, Please accept my resignation from the Apache Velocity PMC -- my time for volunteer efforts has dwindled and it's time to make it official. Been a pleasure being part of this community over the last 15 years and look forward to bumping into some of you at conferences, online, etc in the future. Cheers, WILL - To unsubscribe, e-mail: private-unsubscr...@velocity.apache.org For additional commands, e-mail: private-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: need help with site update
Merged and publish. By the way, it's maybe a good time to recall everyone that site publishing is really easy now that it has been dockerized, and it boils down to calling a single shell script. See this doc: http://velocity.apache.org/site-building.html#building-the-site-with-docker On 2021-03-10 08 h 20, Will Glass-Husain wrote: Hi-- Claude -- would you be able to help with a site update? I made a PR on Github https://github.com/apache/velocity-site/pull/6 This has an update to our project news re the two recently announced CVEs. I'm not sure how to actually get this on our site. Thanks, WILL - 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-939) Download page must mention verification
[ https://issues.apache.org/jira/browse/VELOCITY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-939. - Assignee: Claude Brisson Resolution: Fixed "Verifying integrity" section added. Thanks for the report. > Download page must mention verification > --- > > Key: VELOCITY-939 > URL: https://issues.apache.org/jira/browse/VELOCITY-939 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Assignee: Claude Brisson >Priority: Major > > Download pages must mention the need to verify downloaded artifacts and > describe how to do so using KEYS and/or hashes -- 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-939) Download page must mention verification
[ https://issues.apache.org/jira/browse/VELOCITY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-939. --- > Download page must mention verification > --- > > Key: VELOCITY-939 > URL: https://issues.apache.org/jira/browse/VELOCITY-939 > Project: Velocity > Issue Type: Bug >Reporter: Sebb > Assignee: Claude Brisson >Priority: Major > > Download pages must mention the need to verify downloaded artifacts and > describe how to do so using KEYS and/or hashes -- 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
[ANNOUNCE] Velocity Tools 3.1 released
The Apache Velocity team is pleased to announce the release of Velocity Tools 3.1. Velocity Tools is a library of template tools and helpers to ease the use of the Apache Velocity template engine in standalone applications and webapps. Main changes in this release: * Added an optional 'factory' attribute to tools with the classname of a factory for creating new tools instances. * Added a new BreadcrumbTool meant to help displaying UI breadcrumb trails. * Fixed a potential XSS vulterability in VelocityViewServlet error handling. For a full list of changes, consult the Velocity Tools 3.1 Changes section: https://velocity.apache.org/tools/3.1/changes.html as well as the JIRA changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310130=12345408 For notes on upgrading, see Velocity Tools 3.1 Upgrading section: http://velocity.apache.org/tools/3.1/upgrading.html Regards, the Apache Velocity team. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-938) Broken links for spring-velocity-support
[ https://issues.apache.org/jira/browse/VELOCITY-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-938. --- Assignee: Claude Brisson > Broken links for spring-velocity-support > > > Key: VELOCITY-938 > URL: https://issues.apache.org/jira/browse/VELOCITY-938 > Project: Velocity > Issue Type: Bug >Reporter: Sebb > Assignee: Claude Brisson >Priority: Major > > The links for spring-velocity-support are broken - looks like wrong file names -- 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-938) Broken links for spring-velocity-support
[ https://issues.apache.org/jira/browse/VELOCITY-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-938. - Resolution: Fixed Thanks, fixed. > Broken links for spring-velocity-support > > > Key: VELOCITY-938 > URL: https://issues.apache.org/jira/browse/VELOCITY-938 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The links for spring-velocity-support are broken - looks like wrong file names -- 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-936) Download page issues
[ https://issues.apache.org/jira/browse/VELOCITY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-936. - Resolution: Fixed Snaphot releases removed, archives linked to the archive server. > Download page issues > > > Key: VELOCITY-936 > URL: https://issues.apache.org/jira/browse/VELOCITY-936 > Project: Velocity > Issue Type: Bug > Environment: https://velocity.apache.org/download.cgi >Reporter: Sebb >Priority: Major > > The download page has some issues. > Snapshot releases are only intended for developers, and must not be published > on pages intended for the general public [1] > Also there are references to archived releases [2]. These should be linked > from the archive server ([https://archive.apache.org/dist/velocity/),] and > the files removed from the mirrors. > It's unfair to expect the volunteer mirrors to carry archived versions. > [1] [https://www.apache.org/legal/release-policy.html#publication] > [2] https://velocity.apache.org/download.cgi#archived-components-releases > > > -- 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-936) Download page issues
[ https://issues.apache.org/jira/browse/VELOCITY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-936. --- > Download page issues > > > Key: VELOCITY-936 > URL: https://issues.apache.org/jira/browse/VELOCITY-936 > Project: Velocity > Issue Type: Bug > Environment: https://velocity.apache.org/download.cgi >Reporter: Sebb > Assignee: Claude Brisson >Priority: Major > > The download page has some issues. > Snapshot releases are only intended for developers, and must not be published > on pages intended for the general public [1] > Also there are references to archived releases [2]. These should be linked > from the archive server ([https://archive.apache.org/dist/velocity/),] and > the files removed from the mirrors. > It's unfair to expect the volunteer mirrors to carry archived versions. > [1] [https://www.apache.org/legal/release-policy.html#publication] > [2] https://velocity.apache.org/download.cgi#archived-components-releases > > > -- 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
[RESULT] [VOTE] Tools 3.1 RC1 Release quality
Six binding +1 for GA. A record! On 2021-03-01 21 h 26, Claude Brisson wrote: The Velocity Tools 3.1 RC1 is available since February 27. Main changes in this release: + Added an optional 'factory' attribute to tools with the classname of a factory for creating new tools instances + Added a new BreadcrumbTool meant to help displaying UI breadcrumb trails + Fix potential XSS vulterability in VelocityViewServlet error handling. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1037 Documentation: * https://velocity.apache.org/tools/3.1 Sources: * https://github.com/apache/velocity-tools/releases/tag/3.1-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 AND velocity-engine version 2.3 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install $ cd .. $ git clone --branch 2.3-RC1 https://github.com/apache/velocity-engine.git $ cd velocity-engine $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[RESULT] [VOTE] Engine 2.3 RC2 Release quality
Five binding +1 for GA. Release is underway. On 2021-03-03 13 h 29, Claude Brisson wrote: The Velocity Engine 2.3 RC2 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Changes from RC1 to RC2: + Fixes in testcases for OpenJDK 11 and 15 + Review alternate values implementation, with added testcases Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1038 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master/pom $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[RESULT] [VOTE] Release Velocity Master version 4
Five binding +1s, one non-binding +1. It's a go. On 2021-02-27 11 h 15, Claude Brisson wrote: Hi. Here's an RC for velocity-master-4, with the following changes: + set maven-enforcer-plugin and extra-enforcer-rules plugins versions + removed Antonio as emeritus, as per his request + switched scm URLs from svn to git + added README.md file + updated apache parent to 23 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1035/ https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip Source release checksum(s): velocity-master-4-source-release.zip sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Engine 2.3 RC1 Release quality
You're quite correct in distinguishing the JVM and the language. I'm not sure that Java (the language) and C++ are in the same problem space. I see Rust as a kind of new C++, but about the Java language, it's especially the growing wave of Kotlin that makes me think that the use of the Java language is getting a bit out of fashion. But don't get me wrong. Yes, the term "legacy" was too strong, and Java is well alive. I heard devops talking among themselves, and stating that "Hopefully, PHP still has bright days ahead"... Claude On 21-03-03 19 h 22, Henning Schmiedehausen wrote: No worries. I would not fully agree with "Java becoming legacy"; the Java programming language might, but the JVM ecosystem (especially with GraalVM) and all the new and exciting languages is not. Licensing IMHO is pretty straightforward: Use OpenJDK in its different flavors (usually the RHEL/Ubuntu versions on Linux and AdoptOpenJDK or Corretto anywhere else) or, if you have money to spend, license from Oracle. JDK8 is obsolete, Java 11 is the standard LTS release so everything *should* build with 11. 16 is around the corner (with full support of Alpine as the most exciting thing in there at least for me). And 17 which will arrive in September then wraps all of this into a nice LTS bundle and build a strong new foundation for the next years. Don't get me wrong; I am excited about Rust and its possibilities, especially in connection with WebAssembly. But Java is far from "legacy". It is still way younger than C++ and no one would call that "legacy". :-) -h On Wed, Mar 3, 2021 at 2:36 AM Claude Brisson wrote: Thanks for the review, Henning. I found a little bug myself, I was considering putting it aside for the next release, but working on all JDKs seems an important goal. Even if Oracle licensing went somehow rogue... By the way, I like how most open source projects decided that JDK 8 was the norm. Anyhow, Java itself is slowly becoming legacy. So let's go for an RC2. I don't know at all why you don't have the karma to merge your PR. On 21-03-02 21 h 16, Henning Schmiedehausen wrote: Builds and passes all tests with AdoptOpenJDK 8 on MacOS 11. Fails tests on Java 11 and 15 (3 failures, all related to internal changes in the JDK and brittle tests) I am somewhat 0 on this release, I don't really want to hold it up or make Claude do another round. All the fixes (that make this pass all the tests on JDK 11 and 15) are here: https://github.com/apache/velocity-engine/pull/20 I know that Apache is commit-then-review, but hey, github. -h (First PR to velocity in ages. :-) ) On Mon, Mar 1, 2021 at 8:06 AM Claude Brisson The Velocity Engine 2.3 RC1 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1036 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - 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] Engine 2.3 RC2 Release quality
+1 for GA. On 21-03-03 13 h 29, Claude Brisson wrote: The Velocity Engine 2.3 RC2 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Changes from RC1 to RC2: + Fixes in testcases for OpenJDK 11 and 15 + Review alternate values implementation, with added testcases Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1038 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master/pom $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[VOTE] Engine 2.3 RC2 Release quality
The Velocity Engine 2.3 RC2 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Changes from RC1 to RC2: + Fixes in testcases for OpenJDK 11 and 15 + Review alternate values implementation, with added testcases Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1038 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master/pom $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Engine 2.3 RC1 Release quality
Thanks for the review, Henning. I found a little bug myself, I was considering putting it aside for the next release, but working on all JDKs seems an important goal. Even if Oracle licensing went somehow rogue... By the way, I like how most open source projects decided that JDK 8 was the norm. Anyhow, Java itself is slowly becoming legacy. So let's go for an RC2. I don't know at all why you don't have the karma to merge your PR. On 21-03-02 21 h 16, Henning Schmiedehausen wrote: Builds and passes all tests with AdoptOpenJDK 8 on MacOS 11. Fails tests on Java 11 and 15 (3 failures, all related to internal changes in the JDK and brittle tests) I am somewhat 0 on this release, I don't really want to hold it up or make Claude do another round. All the fixes (that make this pass all the tests on JDK 11 and 15) are here: https://github.com/apache/velocity-engine/pull/20 I know that Apache is commit-then-review, but hey, github. -h (First PR to velocity in ages. :-) ) On Mon, Mar 1, 2021 at 8:06 AM Claude Brisson wrote: The Velocity Engine 2.3 RC1 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1036 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Tools 3.1 RC1 Release quality
+1 for GA On 21-03-01 21 h 26, Claude Brisson wrote: The Velocity Tools 3.1 RC1 is available since February 27. Main changes in this release: + Added an optional 'factory' attribute to tools with the classname of a factory for creating new tools instances + Added a new BreadcrumbTool meant to help displaying UI breadcrumb trails + Fix potential XSS vulterability in VelocityViewServlet error handling. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1037 Documentation: * https://velocity.apache.org/tools/3.1 Sources: * https://github.com/apache/velocity-tools/releases/tag/3.1-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 AND velocity-engine version 2.3 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install $ cd .. $ git clone --branch 2.3-RC1 https://github.com/apache/velocity-engine.git $ cd velocity-engine $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[VOTE] Tools 3.1 RC1 Release quality
The Velocity Tools 3.1 RC1 is available since February 27. Main changes in this release: + Added an optional 'factory' attribute to tools with the classname of a factory for creating new tools instances + Added a new BreadcrumbTool meant to help displaying UI breadcrumb trails + Fix potential XSS vulterability in VelocityViewServlet error handling. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1037 Documentation: * https://velocity.apache.org/tools/3.1 Sources: * https://github.com/apache/velocity-tools/releases/tag/3.1-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 AND velocity-engine version 2.3 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install $ cd .. $ git clone --branch 2.3-RC1 https://github.com/apache/velocity-engine.git $ cd velocity-engine $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Engine 2.3 RC1 Release quality
+1 On 21-03-01 17 h 06, Claude Brisson wrote: The Velocity Engine 2.3 RC1 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1036 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[VOTE] Engine 2.3 RC1 Release quality
The Velocity Engine 2.3 RC1 is available since February 27. Main changes in this release: + New spring-velocity-support module, containing Spring framework Velocity Engine integration classes. + Security fix: let SecureUberspector block methods on ClassLoader and subclasses. Release notes: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html Distribution: * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/ Maven 2 staging repository: * https://repository.apache.org/content/repositories/orgapachevelocity-1036 Documentation: * http://velocity.apache.org/engine/2.3/ Sources: * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 Please note than when evaluating this module, you will need to also install velocity-master version 4 to your local maven repository, with commands like: $ git clone --branch velocity-master-4 https://github.com/apache/velocity-master.git $ cd velocity-master $ mvn install If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Master version 4
BTW, the given signature is sha256, not sha512, my bad. On 21-02-28 08 h 24, Will Glass-Husain wrote: +1 to release this On Sat, Feb 27, 2021 at 8:39 PM Henning Schmiedehausen wrote: +1 to release this. -h -- Forwarded message - From: Henning Schmiedehausen Date: Sat, Feb 27, 2021 at 20:07 Subject: Re: [VOTE] Release Velocity Master version 4 To: Nathan Bubna Ok. Thanks. +1 to release. On Sat, Feb 27, 2021 at 20:06 Nathan Bubna wrote: Hmm. I didn't check the SHA. Not sure on that. As for the "mostly empty", this is the release of the Velocity Master POM. That's all that should be in it. Votes for Tools and Engine releases will come shortly, methinks. On Sat, Feb 27, 2021 at 4:45 PM Henning Schmiedehausen < hgsch...@gmail.com> wrote: Hi Nathan, I have been out of the loop for quite some time, but the repos seem to be mostly empty to me and they do not match the sha: sha512sum ~/Downloads/velocity-master-4-source-release.zip 8b7566ebf696e529de8d79a1443418a818be3169b71682f434fdcb30367ab858cc42922b456bd9e87846fdf9aee6fad7e2e6de79d6fbf3091c0beded65a69b09 /Users/henning/Downloads/velocity-master-4-source-release.zip unzip -l ~/Downloads/velocity-master-4-source-release.zip Archive: /Users/henning/Downloads/velocity-master-4-source-release.zip Length DateTimeName - -- - 0 01-22-2020 15:10 velocity-master-4/ 7769 01-22-2020 15:10 velocity-master-4/pom.xml 271 01-22-2020 15:10 velocity-master-4/DEPENDENCIES 11358 01-22-2020 15:10 velocity-master-4/LICENSE 178 01-22-2020 15:10 velocity-master-4/NOTICE - --- 19576 5 files Am I doing this right? -h On Sat, Feb 27, 2021 at 7:57 AM Nathan Bubna wrote: Hey gents, The board is breathing down our necks because there's a public (but minor) security issue. Claude's put a bunch of work in to make this happen. Please jump in with some quick checks and votes (or even trust and vote, if need be), so we can get the master pom, engine, and tools releases out promptly. Thanks, Your friendly neighborhood PMC chair. -- Forwarded message ----- From: Claude Brisson Date: Sat, Feb 27, 2021 at 2:15 AM Subject: [VOTE] Release Velocity Master version 4 To: Velocity Developers List Hi. Here's an RC for velocity-master-4, with the following changes: + set maven-enforcer-plugin and extra-enforcer-rules plugins versions + removed Antonio as emeritus, as per his request + switched scm URLs from svn to git + added README.md file + updated apache parent to 23 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1035/ https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip Source release checksum(s): velocity-master-4-source-release.zip sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Master version 4
The README.md file doesn't appear anywhere else than on the github front page (and of course at the root of the repo). I guess I shouldn't even have mentioned it in the changelog. I can't do much about the NOTICE year, I think it comes from the apache parent pom. On 21-02-28 00 h 37, Martin Grigorov wrote: On Sat, Feb 27, 2021 at 12:15 PM Claude Brisson wrote: Hi. Here's an RC for velocity-master-4, with the following changes: + set maven-enforcer-plugin and extra-enforcer-rules plugins versions + removed Antonio as emeritus, as per his request + switched scm URLs from svn to git + added README.md file + updated apache parent to 23 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1035/ https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip Source release checksum(s): velocity-master-4-source-release.zip sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 (non-binding) Two small notes: 1) "+ added README.md file" - it is not in the .zip. 2) the NOTICE file says 2020. Maybe it should be updated to 2021 ?! Regards, Martin - 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] [Commented] (VELOCITY-907) Moderators needed for general list
[ https://issues.apache.org/jira/browse/VELOCITY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292864#comment-17292864 ] Claude Brisson commented on VELOCITY-907: - Yes, of course, I don't see why not, since you're already a PMC in several other Apache projects. > Moderators needed for general list > -- > > Key: VELOCITY-907 > URL: https://issues.apache.org/jira/browse/VELOCITY-907 > Project: Velocity > Issue Type: Bug >Reporter: Sebb >Priority: Major > > There are currently no moderators for the -commits@- or general@ lists [1] > Some volunteers need to step up. > In the meantime I have added myself, but that can only be temporary. > [1] > [https://whimsy.apache.org/roster/committee/velocity#mail|https://whimsy.apache.org/roster/committee/santuario#mail] -- 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: [ANNOUCE] Velocity Engine 2.3 test build available
Strangely enough, the github and gitbox versions seem out of sync...
maybe a cache problem somewhere. I pushed my commits on gitbox.
Outdated changelog on gitbox (at least for me) :
https://gitbox.apache.org/repos/asf?p=velocity-engine.git;a=blob_plain;f=src/changes/changes.xml;hb=HEAD
Up to date changelog on github:
https://github.com/apache/velocity-engine/blob/master/src/changes/changes.xml
On 21-03-01 02 h 52, Nate Chadwick wrote:
It would be helpful to know the change list. Even if it is XML format
could you attach?
-n
On Sun, Feb 28, 2021 at 3:24 PM Claude Brisson
wrote:
Yes, Greg. It's a "normal" behavior, we're trying to release
velocity-master (it's just a parent pom gathering some infos),
velocity-engine and velocity-tools in the same process. So you *have* to
clone and install manually velocity-master-4 in your local repository
before trying to use 2.3, with commands like :
$ git clone --branch velocity-master-4
https://github.com/apache/velocity-master.git
$ cd velocity-master
$ mvn install
On 21-02-28 09 h 04, Greg Huber wrote:
Previously I have used the below for maven, now I get
[ERROR] Failed to execute goal on project events: Could not resolve
dependencies for project my.war: Failed to collect dependencies at
org.apache.velocity:velocity-engine-core:jar:2.3: Failed to read
artifact descriptor for
org.apache.velocity:velocity-engine-core:jar:2.3: Could not find
artifact org.apache.velocity:velocity-master:pom:4 in
velocity.snapshots
(
https://repository.apache.org/content/repositories/orgapachevelocity-1036/)
-> [Help 1]
velocity.snapshots
ASF Maven 2 Snapshot
https://repository.apache.org/content/repositories/orgapachevelocity-1036/
true
always
warn
true
always
warn
org.apache.velocity
velocity-engine-core
2.3
Any ideas, I have removed the .m2 velocity folder before the build.
On 27/02/2021 13:13, Claude Brisson wrote:
The test build of Velocity Engine 2.3 RC1 is available.
No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Velocity Engine 2.3 RC1 has been made, and at this time it is simply
a "test build". We welcome any comments you may have, and will take
all feedback into account if a quality vote is called for this build.
Release notes:
*
https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html
Distribution:
* https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/
Maven 2 staging repository:
*
https://repository.apache.org/content/repositories/orgapachevelocity-1036
Documentation:
* http://velocity.apache.org/engine/2.3/
Sources:
* https://gitbox.apache.org/repos/asf?p=velocity-engine.git
* https://github.com/apache/velocity-engine
A vote regarding the quality of this test build will be initiated soon.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
-
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
[ANNOUNCE] Velocity Tools 3.1 test build available (RC1)
The test build of Velocity Tools 3.1 is available.
No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Velocity Tools 3.0 has been made, and at this time it is simply a "test
build". We welcome any comments you may have, and will take all feedback
into account if a quality vote is called for this build.
Release notes:
*
https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html
Distribution:
* https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/
Maven 2 staging repository:
*
https://repository.apache.org/content/repositories/orgapachevelocity-1037
A vote regarding the quality of this test build will be initiated within
the next couple of days.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[ANNOUNCE] Velocity Tools 3.1 test build available (RC1)
The test build of Velocity Tools 3.1 is available.
No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Velocity Tools 3.1 has been made, and at this time it is simply a "test
build". We welcome any comments you may have, and will take all feedback
into account if a quality vote is called for this build.
Release notes:
*
https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html
Distribution:
* https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/
Maven 2 staging repository:
*
https://repository.apache.org/content/repositories/orgapachevelocity-1037
A vote regarding the quality of this test build will be initiated within
the next couple of days.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [ANNOUCE] Velocity Engine 2.3 test build available
Yes, Greg. It's a "normal" behavior, we're trying to release
velocity-master (it's just a parent pom gathering some infos),
velocity-engine and velocity-tools in the same process. So you *have* to
clone and install manually velocity-master-4 in your local repository
before trying to use 2.3, with commands like :
$ git clone --branch velocity-master-4
https://github.com/apache/velocity-master.git
$ cd velocity-master
$ mvn install
On 21-02-28 09 h 04, Greg Huber wrote:
Previously I have used the below for maven, now I get
[ERROR] Failed to execute goal on project events: Could not resolve
dependencies for project my.war: Failed to collect dependencies at
org.apache.velocity:velocity-engine-core:jar:2.3: Failed to read
artifact descriptor for
org.apache.velocity:velocity-engine-core:jar:2.3: Could not find
artifact org.apache.velocity:velocity-master:pom:4 in
velocity.snapshots
(https://repository.apache.org/content/repositories/orgapachevelocity-1036/)
-> [Help 1]
velocity.snapshots
ASF Maven 2 Snapshot
https://repository.apache.org/content/repositories/orgapachevelocity-1036/
true
always
warn
true
always
warn
org.apache.velocity
velocity-engine-core
2.3
Any ideas, I have removed the .m2 velocity folder before the build.
On 27/02/2021 13:13, Claude Brisson wrote:
The test build of Velocity Engine 2.3 RC1 is available.
No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Velocity Engine 2.3 RC1 has been made, and at this time it is simply
a "test build". We welcome any comments you may have, and will take
all feedback into account if a quality vote is called for this build.
Release notes:
*
https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html
Distribution:
* https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/
Maven 2 staging repository:
*
https://repository.apache.org/content/repositories/orgapachevelocity-1036
Documentation:
* http://velocity.apache.org/engine/2.3/
Sources:
* https://gitbox.apache.org/repos/asf?p=velocity-engine.git
* https://github.com/apache/velocity-engine
A vote regarding the quality of this test build will be initiated soon.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
-
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: [ANNOUCE] Velocity Engine 2.3 test build available
This page lists two main changes: - Fix a minor security issue in user-edited templates applications: let SecureUberspector block methods on ClassLoader and subclasses. - New spring-velocity-support module for Velocity Engine integration in Spring Framework. but the linked https://velocity.apache.org/engine/2.3/changes.html is empty. I just found the bug. The site building script expected to find an src/changes/changes.xml at the tag 2.3, while the real tag is (for now) 2.3-rc1. We switched from svn to git last year, so the release process lacks a policy for tags. I did include the rc number in the tag because for master I had to rollback once my changes and found myself deleting a git tag, potentially already checked out somewhere. The idea is to copy the successful rc tag towards 2.3. I just means another step in the process, as this recent bug shows us, but this way tags are permanent. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELTOOLS-182.
---
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
> Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.1
>
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.max(0)}} (just one arg) but at least that could be
> considered a usage error.
--
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] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELTOOLS-182.
-
Fix Version/s: 3.1
Assignee: Claude Brisson
Resolution: Fixed
Fixed
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
> Assignee: Claude Brisson
>Priority: Major
> Fix For: 3.1
>
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.max(0)}} (just one arg) but at least that could be
> considered a usage error.
--
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
[ANNOUCE] Velocity Engine 2.3 test build available
The test build of Velocity Engine 2.3 RC1 is available.
No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Velocity Engine 2.3 RC1 has been made, and at this time it is simply a
"test build". We welcome any comments you may have, and will take all
feedback into account if a quality vote is called for this build.
Release notes:
*
https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/release-notes.html
Distribution:
* https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.3/
Maven 2 staging repository:
*
https://repository.apache.org/content/repositories/orgapachevelocity-1036
Documentation:
* http://velocity.apache.org/engine/2.3/
Sources:
* https://gitbox.apache.org/repos/asf?p=velocity-engine.git
* https://github.com/apache/velocity-engine
A vote regarding the quality of this test build will be initiated soon.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
Fwd: Broken: apache/velocity-engine#21 (master - 1a22c95)
Of course, anticipating upon yet unreleased artifacts breaks CI. But if we are to release master, engine and the tools in a raw ASAP to please the security team, we should launch parallel release processes and let Travis cry. It just means that one must install parent artifacts when validating a dependent one. Forwarded Message Subject:Broken: apache/velocity-engine#21 (master - 1a22c95) Date: Sat, 27 Feb 2021 11:01:22 + From: Travis CI To: cla...@renegat.net apache / velocity-engine <https://travis-ci.com/github/apache/velocity-engine?utm_medium=notification_source=email> branch iconmaster <https://github.com/apache/velocity-engine/tree/master> build has failed Build #21 was broken <https://travis-ci.com/github/apache/velocity-engine/builds/218432260?utm_medium=notification_source=email> arrow to build time clock icon1 min and 15 secs Claude Brisson avatarClaude Brisson 1a22c95 CHANGESET → <https://github.com/apache/velocity-engine/compare/aade2612b1f9...1a22c9542718> [engine] Anticipate master version increment Want to know about upcoming build environment updates? Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! SIGN UP HERE <http://eepurl.com/9OCsP> book icon Documentation <https://docs.travis-ci.com/> about Travis CI Have any questions? We're here to help. <mailto:supp...@travis-ci.com> Unsubscribe <https://travis-ci.com/account/preferences/unsubscribe?repository=16807037_medium=notification_source=email> from build emails from the apache/velocity-engine repository. To unsubscribe from *all* build emails, please update your settings <https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email>. black and white travis ci logo <https://travis-ci.com> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy Jacops | Contact: cont...@travis-ci.com <mailto:cont...@travis-ci.com> | Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: DE282002648
[jira] [Commented] (VELOCITY-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292097#comment-17292097 ] Claude Brisson commented on VELOCITY-933: - [~timcolson] Found and fixed, thanks. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 > Reporter: Claude Brisson > Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-933. - Resolution: Fixed Merged to master. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 > Reporter: Claude Brisson > Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-931) SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292096#comment-17292096 ] Claude Brisson commented on VELOCITY-931: - Ok, found and fixed. > SecureUberspector should block methods on ClassLoader and subclasses > > > Key: VELOCITY-931 > URL: https://issues.apache.org/jira/browse/VELOCITY-931 > Project: Velocity > Issue Type: Improvement >Reporter: William Glass-Husain >Assignee: William Glass-Husain >Priority: Major > Fix For: 2.3 > > > Currently, SecureUberspector matches classes stored with property > "introspector.restrict.classes", which includes ClassLoader. It then > matches exact class names and blocks all methods from being called on that > class. > However, in most cases it's actually a subclass of ClassLoader that's > available in the context, which under normal circumstances would not be > blocked. > My proposal – treat this as a special case. (Remove it from the > configuration). If the class being inspected is assignable from ClassLoader, > then block it. > You could make an argument that all the SecureUberspector should check if the > class isAssignable from all configured classes, but I am concerned about > possible performance penalties. I'd argue that we should hard code checks > for a few special internal classes but force the user to configure other > specific classes themselves. > -- 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] [Issue Comment Deleted] (VELOCITY-931) SecureUberspector should block methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson updated VELOCITY-931: Comment: was deleted (was: Ok, found and fixed.) > SecureUberspector should block methods on ClassLoader and subclasses > > > Key: VELOCITY-931 > URL: https://issues.apache.org/jira/browse/VELOCITY-931 > Project: Velocity > Issue Type: Improvement >Reporter: William Glass-Husain >Assignee: William Glass-Husain >Priority: Major > Fix For: 2.3 > > > Currently, SecureUberspector matches classes stored with property > "introspector.restrict.classes", which includes ClassLoader. It then > matches exact class names and blocks all methods from being called on that > class. > However, in most cases it's actually a subclass of ClassLoader that's > available in the context, which under normal circumstances would not be > blocked. > My proposal – treat this as a special case. (Remove it from the > configuration). If the class being inspected is assignable from ClassLoader, > then block it. > You could make an argument that all the SecureUberspector should check if the > class isAssignable from all configured classes, but I am concerned about > possible performance penalties. I'd argue that we should hard code checks > for a few special internal classes but force the user to configure other > specific classes themselves. > -- 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: [VOTE] Release Velocity Master version 4
+1 On 21-02-27 11 h 15, Claude Brisson wrote: Hi. Here's an RC for velocity-master-4, with the following changes: + set maven-enforcer-plugin and extra-enforcer-rules plugins versions + removed Antonio as emeritus, as per his request + switched scm URLs from svn to git + added README.md file + updated apache parent to 23 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1035/ https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip Source release checksum(s): velocity-master-4-source-release.zip sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[VOTE] Release Velocity Master version 4
Hi. Here's an RC for velocity-master-4, with the following changes: + set maven-enforcer-plugin and extra-enforcer-rules plugins versions + removed Antonio as emeritus, as per his request + switched scm URLs from svn to git + added README.md file + updated apache parent to 23 Staging repo: https://repository.apache.org/content/repositories/orgapachevelocity-1035/ https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip Source release checksum(s): velocity-master-4-source-release.zip sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-932) Resource not found when executing jar file, works fine in IDE
[
https://issues.apache.org/jira/browse/VELOCITY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson closed VELOCITY-932.
---
Assignee: Claude Brisson
> Resource not found when executing jar file, works fine in IDE
> -
>
> Key: VELOCITY-932
> URL: https://issues.apache.org/jira/browse/VELOCITY-932
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: local
>Reporter: ecstasy
>Assignee: Claude Brisson
>Priority: Major
> Attachments: TestVelocity_src.zip
>
>
> Hello, I have a simple maven project with 1 class file. The project works
> fine in eclipse but when creating a jar out of it and executing it, it runs
> into error of ResourceNotFound
>
> {code:java}
> SEVERE: ResourceManager : unable to find resource
> '\templates\welcomeLetter.vm' in any resource loader.
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find resource '\templates\welcomeLetter.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:474)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:352)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1533)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1514)
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:373)
> at
> net.rajanpanchal.handlers.WelcomeLetterGeneratorHandler.(WelcomeLetterGeneratorHandler.java:48)
> {code}
>
> Class file:
> {code:java}
> public class WelcomeLetterGeneratorHandler implements
> RequestHandler, String> {
> String fileObjKeyName = "welcome_letter.txt";
> static VelocityContext vContext;
> static Template t;
>
> static {
> // Create a new Velocity Engine
> VelocityEngine velocityEngine = new VelocityEngine();
> // Set properties that allow reading vm file from classpath.
> Properties p = new Properties();
> velocityEngine.setProperty(RuntimeConstants.RESOURCE_LOADER,
> "file,class,classpath");
> velocityEngine.setProperty("class.resource.loader.class",
>
> "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> velocityEngine.setProperty("file.resource.loader.path",
> "classpath");
> try {
> velocityEngine.init(p);
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> // read the template from resources folder
> System.out.println("Current
> dir:"+System.getProperty("user.dir"));
> try {
> t =
> velocityEngine.getTemplate("\\templates\\welcomeLetter.vm");
> } catch (ResourceNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParseErrorException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } vContext = new VelocityContext();
> } public String handleRequest(Map event, Context
> context) {
> String response = new String("200 OK");
> try {
> // Add data to velocity context
> vContext.put("name", "Joe");
> File f = new File(fileObjKeyName);
> FileWriter writer = new FileWriter(f);
> // merge template and Data
> t.merge(vContext, writer);
> writer.flush();
> writer.close(); } catch (Exception ex) {
> throw new RuntimeException(ex);
> } return response;
> }
>
> public st
[jira] [Resolved] (VELOCITY-932) Resource not found when executing jar file, works fine in IDE
[
https://issues.apache.org/jira/browse/VELOCITY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-932.
-
Resolution: Not A Bug
> Resource not found when executing jar file, works fine in IDE
> -
>
> Key: VELOCITY-932
> URL: https://issues.apache.org/jira/browse/VELOCITY-932
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: local
>Reporter: ecstasy
>Priority: Major
> Attachments: TestVelocity_src.zip
>
>
> Hello, I have a simple maven project with 1 class file. The project works
> fine in eclipse but when creating a jar out of it and executing it, it runs
> into error of ResourceNotFound
>
> {code:java}
> SEVERE: ResourceManager : unable to find resource
> '\templates\welcomeLetter.vm' in any resource loader.
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find resource '\templates\welcomeLetter.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:474)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:352)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1533)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1514)
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:373)
> at
> net.rajanpanchal.handlers.WelcomeLetterGeneratorHandler.(WelcomeLetterGeneratorHandler.java:48)
> {code}
>
> Class file:
> {code:java}
> public class WelcomeLetterGeneratorHandler implements
> RequestHandler, String> {
> String fileObjKeyName = "welcome_letter.txt";
> static VelocityContext vContext;
> static Template t;
>
> static {
> // Create a new Velocity Engine
> VelocityEngine velocityEngine = new VelocityEngine();
> // Set properties that allow reading vm file from classpath.
> Properties p = new Properties();
> velocityEngine.setProperty(RuntimeConstants.RESOURCE_LOADER,
> "file,class,classpath");
> velocityEngine.setProperty("class.resource.loader.class",
>
> "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> velocityEngine.setProperty("file.resource.loader.path",
> "classpath");
> try {
> velocityEngine.init(p);
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> // read the template from resources folder
> System.out.println("Current
> dir:"+System.getProperty("user.dir"));
> try {
> t =
> velocityEngine.getTemplate("\\templates\\welcomeLetter.vm");
> } catch (ResourceNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParseErrorException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } vContext = new VelocityContext();
> } public String handleRequest(Map event, Context
> context) {
> String response = new String("200 OK");
> try {
> // Add data to velocity context
> vContext.put("name", "Joe");
> File f = new File(fileObjKeyName);
> FileWriter writer = new FileWriter(f);
> // merge template and Data
> t.merge(vContext, writer);
> writer.flush();
> writer.close(); } catch (Exception ex) {
> throw new RuntimeException(ex);
> } return response;
> }
>
> public static void main(String[] args) {
>
[jira] [Commented] (VELOCITY-932) Resource not found when executing jar file, works fine in IDE
[
https://issues.apache.org/jira/browse/VELOCITY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292058#comment-17292058
]
Claude Brisson commented on VELOCITY-932:
-
[~ecstasy] I don't know what you mean by this line:
{code:java}
velocityEngine.setProperty("file.resource.loader.path", "classpath");
{code}
Obviously, you would need to give a real path to this property, something like:
{code:java}
velocityEngine.setProperty("file.resource.loader.path",
System.getProperty("user.dir"));
{code}
> Resource not found when executing jar file, works fine in IDE
> -
>
> Key: VELOCITY-932
> URL: https://issues.apache.org/jira/browse/VELOCITY-932
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7.x, 2.2
> Environment: local
>Reporter: ecstasy
>Priority: Major
> Attachments: TestVelocity_src.zip
>
>
> Hello, I have a simple maven project with 1 class file. The project works
> fine in eclipse but when creating a jar out of it and executing it, it runs
> into error of ResourceNotFound
>
> {code:java}
> SEVERE: ResourceManager : unable to find resource
> '\templates\welcomeLetter.vm' in any resource loader.
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to
> find resource '\templates\welcomeLetter.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:474)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:352)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1533)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1514)
> at
> org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:373)
> at
> net.rajanpanchal.handlers.WelcomeLetterGeneratorHandler.(WelcomeLetterGeneratorHandler.java:48)
> {code}
>
> Class file:
> {code:java}
> public class WelcomeLetterGeneratorHandler implements
> RequestHandler, String> {
> String fileObjKeyName = "welcome_letter.txt";
> static VelocityContext vContext;
> static Template t;
>
> static {
> // Create a new Velocity Engine
> VelocityEngine velocityEngine = new VelocityEngine();
> // Set properties that allow reading vm file from classpath.
> Properties p = new Properties();
> velocityEngine.setProperty(RuntimeConstants.RESOURCE_LOADER,
> "file,class,classpath");
> velocityEngine.setProperty("class.resource.loader.class",
>
> "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> velocityEngine.setProperty("file.resource.loader.path",
> "classpath");
> try {
> velocityEngine.init(p);
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> // read the template from resources folder
> System.out.println("Current
> dir:"+System.getProperty("user.dir"));
> try {
> t =
> velocityEngine.getTemplate("\\templates\\welcomeLetter.vm");
> } catch (ResourceNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParseErrorException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } vContext = new VelocityContext();
> } public String handleRequest(Map event, Context
> context) {
> String response = new String("200 OK");
> try {
> // Add data to velocity context
> vContext.put("name", "Joe");
> File f = new File(fileObjKeyName);
> FileWriter writer = new FileWriter(f)
[jira] [Resolved] (VELOCITY-927) Parsing problem with space before closing curly bracket
[
https://issues.apache.org/jira/browse/VELOCITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-927.
-
Fix Version/s: 2.3
Resolution: Fixed
> Parsing problem with space before closing curly bracket
> ---
>
> Key: VELOCITY-927
> URL: https://issues.apache.org/jira/browse/VELOCITY-927
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
> Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.3
>
>
> After updateing from a slightly outdated velocity 1.x to 2.x wo have some
> issues with our existing templates.
> Some of them are already fixed in 2.2 but at least for now we still have one
> issue.
> This template
> {code:java}
> #set ( $nameMap10 =
> {
> }){code}
> results in
> {code:java}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "}" at
> test[line 3, column 5]
> Was expecting one of:
> "[" ...
> "{" ...
> ...
> ...
> ...
> "true" ...
> "false" ...
> ...
> ...
> ...
> ...
> "{" ...
> "[" ...
> {code}
> it seems that the whitespaces and newlines in this example matter.
> Modifying the tempalte to
> {code:java}
> #set ( $nameMap10 =
> {})
> {code}
> seems to workaround this issue but it would be nice if this would be fixed in
> Velocity.
>
> Here is a small test-case:
> {code:java}
> @Test
> public void testEmptyMap()
> throws Exception
> {
> final String _empty_map = new StringBuilder()
> .append("#set ( $nameMap10 =\n")
> .append("{\n")
> .append("})\n")
> .toString();
> final Template _template = new Template();
> _template.setRuntimeServices(RuntimeSingleton.getRuntimeServices());
> _template.setEncoding(ModuleManager.getInstance().getDefaultEncoding());
> _template.setName("test");
> _template.setData(RuntimeSingleton.getRuntimeServices().parse(new
> StringReader(_empty_map.toString()), _template));
> _template.initDocument();
> final VelocityContext _context = new VelocityContext();
> _template.merge(_context, new StringWriter());
> }
> {code}
--
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-927) Parsing problem with space before closing curly bracket
[
https://issues.apache.org/jira/browse/VELOCITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292057#comment-17292057
]
Claude Brisson commented on VELOCITY-927:
-
Fixed in master.
> Parsing problem with space before closing curly bracket
> ---
>
> Key: VELOCITY-927
> URL: https://issues.apache.org/jira/browse/VELOCITY-927
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.2
>Reporter: Al Bundy
> Assignee: Claude Brisson
>Priority: Major
>
> After updateing from a slightly outdated velocity 1.x to 2.x wo have some
> issues with our existing templates.
> Some of them are already fixed in 2.2 but at least for now we still have one
> issue.
> This template
> {code:java}
> #set ( $nameMap10 =
> {
> }){code}
> results in
> {code:java}
> org.apache.velocity.runtime.parser.TemplateParseException: Encountered "}" at
> test[line 3, column 5]
> Was expecting one of:
> "[" ...
> "{" ...
> ...
> ...
> ...
> "true" ...
> "false" ...
> ...
> ...
> ...
> ...
> "{" ...
> "[" ...
> {code}
> it seems that the whitespaces and newlines in this example matter.
> Modifying the tempalte to
> {code:java}
> #set ( $nameMap10 =
> {})
> {code}
> seems to workaround this issue but it would be nice if this would be fixed in
> Velocity.
>
> Here is a small test-case:
> {code:java}
> @Test
> public void testEmptyMap()
> throws Exception
> {
> final String _empty_map = new StringBuilder()
> .append("#set ( $nameMap10 =\n")
> .append("{\n")
> .append("})\n")
> .toString();
> final Template _template = new Template();
> _template.setRuntimeServices(RuntimeSingleton.getRuntimeServices());
> _template.setEncoding(ModuleManager.getInstance().getDefaultEncoding());
> _template.setName("test");
> _template.setData(RuntimeSingleton.getRuntimeServices().parse(new
> StringReader(_empty_map.toString()), _template));
> _template.initDocument();
> final VelocityContext _context = new VelocityContext();
> _template.merge(_context, new StringWriter());
> }
> {code}
--
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
