Re: Resigning from Apache Velocity PMC
Will, Thank you so much for your time and the part of the journey that we walked together. I hope we still see you around here from time to time. Looking forward to going back to in-person conferences as well, when this is all done, we should get together for beers again. -h On Wed, Mar 10, 2021 at 9:07 PM Will Glass-Husain wrote: > Dear Team, > > Please accept my resignation from the Apache Velocity PMC -- my time > for volunteer efforts has dwindled and it's time to make it official. > > Been a pleasure being part of this community over the last 15 years > and look forward to bumping into some of you at conferences, online, > etc in the future. > > Cheers, > WILL > > - > To unsubscribe, e-mail: private-unsubscr...@velocity.apache.org > For additional commands, e-mail: private-h...@velocity.apache.org > >
Re: [ANNOUNCE] Velocity Tools 3.1 released
Thank you Claude for getting this out! -h On Mon, Mar 8, 2021 at 4:22 PM Claude Brisson wrote: > 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&version=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 > >
Re: [ANNOUCE] Apache Velocity Engine 2.3 Released
Thank you Claude for getting this out! -h On Mon, Mar 8, 2021 at 4:12 PM Claude Brisson wrote: > The Apache Velocity community is pleased to announce the release of > Apache Velocity Engine 2.3 The release is available for download at: > >https://velocity.apache.org/download.cgi > > Apache Velocity is well-known in the Java field as a lightweight, > easy-to-use templating library for creating dynamic web sites and > performing other text-generation tasks. It relies on the Velocity > Template Language (VTL) which is aimed at ease-of-use and simplicity. > > Main changes in this release: > > > * Fix a minor security issue in user-edited templates applications: let > SecureUberspector block methods on ClassLoader and subclasses. > > * New spring-velocity-support module for Velocity Engine integration in > Spring Framework. > > For a full list of changes, consult the Velocity Engine 2.3 Changes > section: > >https://velocity.apache.org/engine/2.3/changes.html > > as well as the JIRA changelog: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310104&version=12348601 > > For notes on upgrading, see Velocity Engine 2.3 Upgrading section: > >http://velocity.apache.org/engine/2.3/upgrading.html > > Regards, > >the Apache Velocity team. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
Re: [VOTE] Engine 2.3 RC1 Release quality
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 > > > 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] Engine 2.3 RC2 Release quality
Builds on JDK 8, 11 and 15 for me on MacOS 11 [X] General Availability (GA) On Wed, Mar 3, 2021 at 4:29 AM Claude Brisson wrote: > The Velocity Engine 2.3 RC2 is available since February 27. > [...] > > Sources: > > * https://github.com/apache/velocity-engine/releases/tag/2.3-RC1 -RC2 ... :-) > > [ ] Leave at test build > [ ] Alpha > [ ] Beta > [ ] General Availability (GA) > > > > - > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
Re: [VOTE] Tools 3.1 RC1 Release quality
Passes for me on JDK 8, 11, 15 [X] General Availability (GA) On Mon, Mar 1, 2021 at 12:26 PM Claude Brisson wrote: > The Velocity Tools 3.1 RC1 is available since February 27. > > Main changes in this release: > > + Added an optional 'factory' attribute to tools with the classname of a > factory for creating new tools instances > + Added a new BreadcrumbTool meant to help displaying UI breadcrumb trails > + Fix potential XSS vulterability in VelocityViewServlet error handling. > > > Release notes: > > * > > https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/release-notes.html > > Distribution: > > * https://dist.apache.org/repos/dist/dev/velocity/velocity-tools/3.1/ > > Maven 2 staging repository: > > * > https://repository.apache.org/content/repositories/orgapachevelocity-1037 > > Documentation: > > * https://velocity.apache.org/tools/3.1 > > Sources: > > * https://github.com/apache/velocity-tools/releases/tag/3.1-RC1 > > Please note than when evaluating this module, you will need to also > install velocity-master version 4 AND velocity-engine version 2.3 to > your local maven repository, with commands like: > > $ git clone --branch velocity-master-4 > https://github.com/apache/velocity-master.git > $ cd velocity-master > $ mvn install > $ cd .. > $ git clone --branch 2.3-RC1 https://github.com/apache/velocity-engine.git > $ cd velocity-engine > $ mvn install > > If you have had a chance to review the test build, please respond with a > vote on its quality: > > > [ ] Leave at test build > [ ] Alpha > [ ] Beta > [ ] General Availability (GA) > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
Re: [GitHub] [velocity-engine] hgschmie opened a new pull request #20: Fixes failing tests on JDK 11+
There is some irony that I could not actually merge it myself. It seems I do not have write access to the velocity repo. -h On Tue, Mar 2, 2021 at 12:14 PM GitBox wrote: > > hgschmie opened a new pull request #20: > URL: https://github.com/apache/velocity-engine/pull/20 > > >Some brittle code tests the messages of exceptions etc. in the tests > which have changed in JDK11+ > >Tested with OpenJDK 11 and OpenJDK 15. > > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.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
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 > >
Fwd: [VOTE] Release Velocity Master version 4
+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 > wrote: > >> Hi Nathan, >> >> I have been out of the loop for quite some time, but the repos seem to be >> mostly empty to me and they do not match the sha: >> >> sha512sum ~/Downloads/velocity-master-4-source-release.zip >> 8b7566ebf696e529de8d79a1443418a818be3169b71682f434fdcb30367ab858cc42922b456bd9e87846fdf9aee6fad7e2e6de79d6fbf3091c0beded65a69b09 >> /Users/henning/Downloads/velocity-master-4-source-release.zip >> >> unzip -l ~/Downloads/velocity-master-4-source-release.zip >> Archive: /Users/henning/Downloads/velocity-master-4-source-release.zip >> Length DateTimeName >> - -- - >> 0 01-22-2020 15:10 velocity-master-4/ >> 7769 01-22-2020 15:10 velocity-master-4/pom.xml >> 271 01-22-2020 15:10 velocity-master-4/DEPENDENCIES >> 11358 01-22-2020 15:10 velocity-master-4/LICENSE >> 178 01-22-2020 15:10 velocity-master-4/NOTICE >> - --- >> 19576 5 files >> >> Am I doing this right? >> >> -h >> >> >> >> >> >> >> On Sat, Feb 27, 2021 at 7:57 AM Nathan Bubna wrote: >> >>> Hey gents, >>> >>> The board is breathing down our necks because there's a public (but >>> minor) security issue. Claude's put a bunch of work in to make this happen. >>> Please jump in with some quick checks and votes (or even trust and vote, if >>> need be), so we can get the master pom, engine, and tools releases out >>> promptly. >>> >>> Thanks, >>> Your friendly neighborhood PMC chair. >>> >>> -- Forwarded message - >>> From: Claude Brisson >>> Date: Sat, Feb 27, 2021 at 2:15 AM >>> Subject: [VOTE] Release Velocity Master version 4 >>> To: Velocity Developers List >>> >>> >>> Hi. >>> >>> Here's an RC for velocity-master-4, with the following changes: >>> >>> + set maven-enforcer-plugin and extra-enforcer-rules plugins versions >>> + removed Antonio as emeritus, as per his request >>> + switched scm URLs from svn to git >>> + added README.md file >>> + updated apache parent to 23 >>> >>> Staging repo: >>> >>> https://repository.apache.org/content/repositories/orgapachevelocity-1035/ >>> >>> https://repository.apache.org/content/repositories/orgapachevelocity-1035/org/apache/velocity/velocity-master/4/velocity-master-4-source-release.zip >>> >>> Source release checksum(s): >>> velocity-master-4-source-release.zip >>> sha512: 3ad7be4cb560428e39448fc67b6b1e9f62886c429b6d633b07749b8638c815a8 >>> >>> Vote open for 72 hours. >>> >>> [ ] +1 >>> [ ] +0 >>> [ ] -1 >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >>> For additional commands, e-mail: dev-h...@velocity.apache.org >>> >>>
Re: [ANNOUNCE] Velocity Engine 2.2 RC6 test build available
You’re right. Still, the engine would benefit from building on newer versions of the JDK. Not the least because you can use the --release switch which is superior to the source/target bootclasspath dance. That requires JDK 9+ to build (you can still use JDK8 as target). -h On Sun, Feb 2, 2020 at 01:26 Michael Osipov wrote: > Am 2020-02-02 um 07:14 schrieb Henning Schmiedehausen: > > Hi Claude, > > > > thank you so much for all the work that went into this RC. I will give > you > > a +0.5 (as there are already three +1, I don't want to hold up the > release) > > > > - builds and passes tests on MacOS running java 8 (OpenJDK 64-Bit Server > VM > > (AdoptOpenJDK)(build 25.222-b10, mixed mode)) > > - build fails on MacOS running java 11 with three failed tests (OpenJDK > > 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)) > > - number of deprecation warnings (lang3, some additional warnings about > JDK > > deprecations for Java 11) > > > > Given that 14 (the next LTS) is just around the corner and Java 8 is > > getting on in age (I applaud that 2.x is Java 8+ only), having a release > > next that focuses on the future (build on 11, maybe even on 14 preview) > may > > be a good thing. > > That's wrong. 14 isn't LTS, 17 is. Java 8 will love for another 5 years. > I don't see a reason to drop it. I'd take Velocity 3.0 as a change to > perform a major cleanup which has been overdue for at least 5 years. > > M > > - > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
Re: [ANNOUNCE] Velocity Engine 2.2 RC6 test build available
oh, another thing (which may be just the way apache works): I literally had
to dig out an svn client and get the code from the svn repo. There is no
tag (neither 2.2 nor 2.2RC6) on github (github.com/apache/velocity-engine).
There are a bunch of other RC tags (for 2.0 and 2.1). This may just be a
quirk on how the git mirror in apache works; but I would have expected to
find the RC tags there.
-h
On Sat, Feb 1, 2020 at 10:14 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:
> Hi Claude,
>
> thank you so much for all the work that went into this RC. I will give you
> a +0.5 (as there are already three +1, I don't want to hold up the release)
>
> - builds and passes tests on MacOS running java 8 (OpenJDK 64-Bit Server
> VM (AdoptOpenJDK)(build 25.222-b10, mixed mode))
> - build fails on MacOS running java 11 with three failed tests (OpenJDK
> 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode))
> - number of deprecation warnings (lang3, some additional warnings about
> JDK deprecations for Java 11)
>
> Given that 14 (the next LTS) is just around the corner and Java 8 is
> getting on in age (I applaud that 2.x is Java 8+ only), having a release
> next that focuses on the future (build on 11, maybe even on 14 preview) may
> be a good thing.
>
> Again, I am glad to see Velocity still being around and developed. I wish
> I had more time to do coding on open source.
>
> -h
>
>
>
>
>
> On Wed, Jan 29, 2020 at 5:05 PM Claude Brisson
> wrote:
>
>> The test build of Velocity Engine 2.2 RC6 is available.
>>
>> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
>> Velocity Engine 2.2 has been made, and at this time it is simply a "test
>> build". We welcome any comments you may have, and will take all feedback
>> into account if a quality vote is called for this build.
>>
>> Release notes:
>>
>> *
>>
>> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/release-notes.html
>>
>>
>> Distribution:
>>
>> * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/
>>
>> Maven 2 staging repository:
>>
>> *
>> https://repository.apache.org/content/repositories/orgapachevelocity-1034/
>>
>> Documentation:
>>
>> * https://velocity.apache.org/engine/2.2/
>>
>> Sources:
>>
>> * https://svn.apache.org/repos/asf/velocity/engine/tags/2.2/
>>
>> Release Candidates History:
>>
>> * RC1 Initial RC
>>
>> * RC2
>> - added BigInteger and BigDecimal implicit conversions
>> - [VELOCITY-923] fixed a parser regression for `$foo||`
>> - [VELOCITY-904] fixed two corner case bugs for the
>> velocimacro.arguments.preserve_literals backward compatibility flag
>> - fixed engine and dependency versions in README and mention the
>> parser customization feature in the *building* section
>> - nicified README links
>> - upgraded surfire plugin version from 2.19.1 to 2.22.1
>> - upgraded maven-jar-plugin from 3.1.1 to 3.2.2
>> - added version 1.2 for extra-enforcer-rules
>> - upgraded maven-javadoc-plugin from 3.1.0 to 3.1.1
>> - upgraded findbugs-maven-plugin from 3.0.4 to 3.0.5
>> - upgraded maven-release-plugin from *unspecified* to 3.0.0-M1
>> - added a new templatized static class
>> org.apache.velocity.runtime.VelocityEngineVersion.java
>> - use the File Separator control character to mark the end of stream
>> for the parser (instead of the zero-width space char)
>> - reviewed packaging of engine examples (refreshed content, plus made
>> them as a standalone zip file with readme, shell scripts, dependencies
>> and examples sources rather than a meaningless standalone pom next to a
>> jar without explanations...)
>>
>> * RC3
>> - [VELOCITY-904] fixed yet another corner case bugs for the
>> velocimacro.arguments.preserve_literals backward compatibility flag
>> - upgraded SLF4J from 1.7.28 to 1.7.30
>>
>> * RC4
>> - [VELOCITY-904] fixed a regression introduced in RC3
>>
>> * RC5
>> - [VELOCITY-924] fixed cache collision between an object and its class
>> - Javadoc fixes in parser genereted classes
>> - [VELOCITY-925] fixed BC whitespace gobbling for macro call without
>> parentheses
>> - [VELOCITY-926] fixed regression: Macro arguments names cannot
>> collide with external references names
>> - upgraded junit from 4.12 to 4.13
>>
>> * RC6
>> - [VELOCITY-926] fixed side effects by deprecating
>> velocimacro.arguments.preserve_literals config flag in favor of
>> velocimacro.enable_bc_mode, which (besides preserving arguments
>> literals) uses global context values as defaults for missing macro
>> arguments without explicit defaults (as did 1.7)
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>
>>
Re: [ANNOUNCE] Velocity Engine 2.2 RC6 test build available
Hi Claude,
thank you so much for all the work that went into this RC. I will give you
a +0.5 (as there are already three +1, I don't want to hold up the release)
- builds and passes tests on MacOS running java 8 (OpenJDK 64-Bit Server VM
(AdoptOpenJDK)(build 25.222-b10, mixed mode))
- build fails on MacOS running java 11 with three failed tests (OpenJDK
64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode))
- number of deprecation warnings (lang3, some additional warnings about JDK
deprecations for Java 11)
Given that 14 (the next LTS) is just around the corner and Java 8 is
getting on in age (I applaud that 2.x is Java 8+ only), having a release
next that focuses on the future (build on 11, maybe even on 14 preview) may
be a good thing.
Again, I am glad to see Velocity still being around and developed. I wish I
had more time to do coding on open source.
-h
On Wed, Jan 29, 2020 at 5:05 PM Claude Brisson
wrote:
> The test build of Velocity Engine 2.2 RC6 is available.
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> Velocity Engine 2.2 has been made, and at this time it is simply a "test
> build". We welcome any comments you may have, and will take all feedback
> into account if a quality vote is called for this build.
>
> Release notes:
>
> *
>
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/release-notes.html
>
>
> Distribution:
>
> * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.2/
>
> Maven 2 staging repository:
>
> *
> https://repository.apache.org/content/repositories/orgapachevelocity-1034/
>
> Documentation:
>
> * https://velocity.apache.org/engine/2.2/
>
> Sources:
>
> * https://svn.apache.org/repos/asf/velocity/engine/tags/2.2/
>
> Release Candidates History:
>
> * RC1 Initial RC
>
> * RC2
> - added BigInteger and BigDecimal implicit conversions
> - [VELOCITY-923] fixed a parser regression for `$foo||`
> - [VELOCITY-904] fixed two corner case bugs for the
> velocimacro.arguments.preserve_literals backward compatibility flag
> - fixed engine and dependency versions in README and mention the
> parser customization feature in the *building* section
> - nicified README links
> - upgraded surfire plugin version from 2.19.1 to 2.22.1
> - upgraded maven-jar-plugin from 3.1.1 to 3.2.2
> - added version 1.2 for extra-enforcer-rules
> - upgraded maven-javadoc-plugin from 3.1.0 to 3.1.1
> - upgraded findbugs-maven-plugin from 3.0.4 to 3.0.5
> - upgraded maven-release-plugin from *unspecified* to 3.0.0-M1
> - added a new templatized static class
> org.apache.velocity.runtime.VelocityEngineVersion.java
> - use the File Separator control character to mark the end of stream
> for the parser (instead of the zero-width space char)
> - reviewed packaging of engine examples (refreshed content, plus made
> them as a standalone zip file with readme, shell scripts, dependencies
> and examples sources rather than a meaningless standalone pom next to a
> jar without explanations...)
>
> * RC3
> - [VELOCITY-904] fixed yet another corner case bugs for the
> velocimacro.arguments.preserve_literals backward compatibility flag
> - upgraded SLF4J from 1.7.28 to 1.7.30
>
> * RC4
> - [VELOCITY-904] fixed a regression introduced in RC3
>
> * RC5
> - [VELOCITY-924] fixed cache collision between an object and its class
> - Javadoc fixes in parser genereted classes
> - [VELOCITY-925] fixed BC whitespace gobbling for macro call without
> parentheses
> - [VELOCITY-926] fixed regression: Macro arguments names cannot
> collide with external references names
> - upgraded junit from 4.12 to 4.13
>
> * RC6
> - [VELOCITY-926] fixed side effects by deprecating
> velocimacro.arguments.preserve_literals config flag in favor of
> velocimacro.enable_bc_mode, which (besides preserving arguments
> literals) uses global context values as defaults for missing macro
> arguments without explicit defaults (as did 1.7)
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>
Re: Building the velocity site
In that case, I would move the actual site code from site/site into just site/ -h On Thu, Nov 4, 2010 at 04:47, Antonio Petrelli wrote: > 2010/11/3 Antonio Petrelli : >> 2010/11/2 Henning Schmiedehausen : >>> - go to site/tools and run "mvn install" >> >> Henning, I noticed I forgot a thing to do on site tools. >> I would like to move them to a distinct part of the SVN repository and >> modify the POM a bit, to be the same as the other projects. >> Would you mind to wait a bit until I've fixed them? I will do it this >> evening CET, I will let you know when I'm finished. > > Done, the new position is: > http://svn.apache.org/repos/asf/velocity/site-tools/trunk > > I deployed a new snapshot for your convenience. > > Thanks for the patience > Antonio > > - > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Building the velocity site
Hi, so after a way too long time, I finally spent some time to fix the various pieces that were/are required to build the Velocity site. Both Nathan and I were able to build the velocity site locally and push it to people.apache.org. Which is great. This is the procedure: - check out https://svn.apache.org/repos/asf/velocity/site into a "site" folder - go to site/tools and run "mvn install" - afterwards, go to site/site and run "mvn clean site" This builds the velocity web site. Running "mvn site:deploy" requires the necessary credentials to push it to people.apache.org but is then straightforward. I will call for vote shortly to release the various tools required to build the site. -h - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [RESULT] Promote mavenized Velocity projects to trunk
(very late) +1 from me, too. -h On Wed, Sep 15, 2010 at 09:28, Antonio Petrelli wrote: > About 5 days have passed, so here are the results: > +1 binding: Nathan, Claude > +1 non binding: Antonio, Sergiu > > I will inform you about the movement to the trunk, I think I can do it > this weekend. > > Thanks > Antonio > > - > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Engine 1.6.3
+1 looks good. -h On Fri, Dec 11, 2009 at 12:48, Nathan Bubna wrote: > Let's push this one out soon folks. The release candidate is available here: > > http://people.apache.org/~nbubna/velocity/engine/1.6.3/ > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > I would really love to see the necessary +1 votes by Monday (12/14) > afternoon, so i can announce a Wed (12/16) release. Please, please > don't leave this vote to drag out or require a re-vote. I may not > have time for this again until the new year. Oh, and please forgive > this little guilt trip. I will still appreciate all of you even if > it doesn't work out, but i'm rather hoping it does happen. :) > > On Mon, Dec 7, 2009 at 4:18 PM, Nathan Bubna wrote: >> Ok, it seems to me that VELOCITY-731 set back performance enough for >> people that we should not wait for 1.7 to have an official release >> with the new "directive.if.tostring.nullcheck" config switch >> available. So, here's a 1.6.3 test build. Please try it out and >> report problems ASAP. :) >> >> http://people.apache.org/~nbubna/velocity/engine/1.6.3/ >> >> I plan to call for a release vote on Fri (12/11), aiming for a 12/16 >> release date. >> >> (personal note: based on rev 888167 in the 1.6.x branch) >> > > - > 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: [VOTE] Velocity Engine 1.6.2 release
Rat report looks good, builds for me with JDK 1.6_10 on Linux (i386, 32 Bit). +1 Ciao Hennig On Tue, 2009-01-27 at 12:37 +0100, Claude Brisson wrote: > Yet another candidate release for 1.6.2, and this time I directly > attempt a vote... > > The release is available here: > > http://people.apache.org/~cbrisson/velocity/engine/1.6.2/ > > So, time to release this build as 1.6.2? > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > The vote is open for at least 72 hours, I'll probably let it run up to > Saturday morning. > > > Claude > > > > - > 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: [VOTE] Velocity Engine 1.6.1 release
Ok, I agree. I turn this into a 0 vote. Ciao Henning Nathan Bubna schrieb: > The reflection problem in 1.6 is obscure, but also not going to have a > simple workaround when it happens. The macro context problem is easy > to workaround but will be more common and annoying. Neither is > terribly severe, but my time is getting increasingly precious as the > new year approaches, and i can less afford to be working on Velocity. > I definitely can rebuild the release, but i absolutely do not consider > a missing license header on a test case worth the time and effort. > There is no realistic or practical reason that the lack of that header > will be problematic for anyone. Even in theory, it is a stretch to > see a show-stopping problem with this. > > On Sat, Dec 13, 2008 at 10:24 PM, Henning Schmiedehausen > wrote: >> Then I missed it back then, which is my mistake. >> >> Bad timng: Yes, probably, is the problem in 1.6 so severe that it does >> not allow rebuilding the tarballs? >> >> I am willing to lift it to a 0 if there are pressing reasons. However, >> it definitely should be fixed in SVN. >> >>Ciao >> Henning >> >> >> >> Nathan Bubna schrieb: >>> On Sat, Dec 13, 2008 at 7:16 PM, Henning Schmiedehausen >>> wrote: >>>> Sorry, -1 due to this: >>>> >>>> !? ./src/test/org/apache/velocity/test/StrictReferenceTestCase.java >>> looks like it was that way when you ran RAT on 1.6 and gave that a +1. >>> what gives? this is lousy timing; is this really worth the veto? >>> >>>> from the rat report. Please fix the license and prepare a new build. >>>> >>>>Ciao >>>>Henning >>>> >>>> >>>> On Fri, 2008-12-12 at 07:38 -0800, Nathan Bubna wrote: >>>>> Ok, there were no complaints about the latest 1.6.1 test build, so it >>>>> is time to vote: >>>>> >>>>> The test build candidate for release is still available here: >>>>> http://people.apache.org/~nbubna/velocity/engine/1.6.1/ >>>>> >>>>> Please vote regarding your support for releasing this test build as >>>>> Velocity Engine 1.6.1: >>>>> >>>>> [ ] +1 Let's do it >>>>> [ ] +0 Have fun; i don't care. >>>>> [ ] -0 Not sure about this, but i won't stop you. >>>>> [ ] -1 No, because __ >>>>> >>>>> The voting period is typically 72 hours, putting its close time as >>>>> roughly 7am PST on Mon, Dec 15th. Vote early and vote often! :) >>>>> >>>>> On Fri, Dec 5, 2008 at 9:58 AM, Nathan Bubna wrote: >>>>>> if you didn't notice, a vararg method reflection bug (VELOCITY-651) >>>>>> was found shortly after we got 1.6 released. it is now fixed, and i >>>>>> think we need to do a bug fix release for it. it's not the sort of >>>>>> thing that should wait around for a 1.7 release. so, here's a test >>>>>> build for 1.6.1. >>>>>> >>>>>> http://people.apache.org/~nbubna/velocity/engine/1.6.1/ >>>>>> >>>>>> please give it a look and a test. i'll probably call for a vote on >>>>>> Tuesday. i'm aiming for a Fri (12/12) release. >>>>>> >>>>>> thanks, >>>>>> nathan >>>>>> >>>>> - >>>>> To unsubscribe, e-mail: private-unsubscr...@velocity.apache.org >>>>> For additional commands, e-mail: private-h...@velocity.apache.org >>>>> >>>> -- >>>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux >>>> Mail: henn...@schmiedehausen.org-- Consultant, Architect, Developer >>>> Web: http://henning.schmiedehausen.org/ >>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >>>> For additional commands, e-mail: dev-h...@velocity.apache.org >>>> >>>> >> >> -- >> Henning P. Schmiedehausen -- henn...@schmiedehausen.org >> >> "Save the cheerleader. Save the world." >> -- Henning P. Schmiedehausen -- henn...@schmiedehausen.org "Save the cheerleader. Save the world." - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Velocity Engine 1.6.1 release
Then I missed it back then, which is my mistake. Bad timng: Yes, probably, is the problem in 1.6 so severe that it does not allow rebuilding the tarballs? I am willing to lift it to a 0 if there are pressing reasons. However, it definitely should be fixed in SVN. Ciao Henning Nathan Bubna schrieb: > On Sat, Dec 13, 2008 at 7:16 PM, Henning Schmiedehausen > wrote: >> Sorry, -1 due to this: >> >> !? ./src/test/org/apache/velocity/test/StrictReferenceTestCase.java > > looks like it was that way when you ran RAT on 1.6 and gave that a +1. > what gives? this is lousy timing; is this really worth the veto? > >> from the rat report. Please fix the license and prepare a new build. >> >>Ciao >>Henning >> >> >> On Fri, 2008-12-12 at 07:38 -0800, Nathan Bubna wrote: >>> Ok, there were no complaints about the latest 1.6.1 test build, so it >>> is time to vote: >>> >>> The test build candidate for release is still available here: >>> http://people.apache.org/~nbubna/velocity/engine/1.6.1/ >>> >>> Please vote regarding your support for releasing this test build as >>> Velocity Engine 1.6.1: >>> >>> [ ] +1 Let's do it >>> [ ] +0 Have fun; i don't care. >>> [ ] -0 Not sure about this, but i won't stop you. >>> [ ] -1 No, because __ >>> >>> The voting period is typically 72 hours, putting its close time as >>> roughly 7am PST on Mon, Dec 15th. Vote early and vote often! :) >>> >>> On Fri, Dec 5, 2008 at 9:58 AM, Nathan Bubna wrote: >>>> if you didn't notice, a vararg method reflection bug (VELOCITY-651) >>>> was found shortly after we got 1.6 released. it is now fixed, and i >>>> think we need to do a bug fix release for it. it's not the sort of >>>> thing that should wait around for a 1.7 release. so, here's a test >>>> build for 1.6.1. >>>> >>>> http://people.apache.org/~nbubna/velocity/engine/1.6.1/ >>>> >>>> please give it a look and a test. i'll probably call for a vote on >>>> Tuesday. i'm aiming for a Fri (12/12) release. >>>> >>>> thanks, >>>> nathan >>>> >>> - >>> To unsubscribe, e-mail: private-unsubscr...@velocity.apache.org >>> For additional commands, e-mail: private-h...@velocity.apache.org >>> >> -- >> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux >> Mail: henn...@schmiedehausen.org-- Consultant, Architect, Developer >> Web: http://henning.schmiedehausen.org/ >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >> For additional commands, e-mail: dev-h...@velocity.apache.org >> >> -- Henning P. Schmiedehausen -- henn...@schmiedehausen.org "Save the cheerleader. Save the world." - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Velocity Engine 1.6.1 release
Sorry, -1 due to this: !? ./src/test/org/apache/velocity/test/StrictReferenceTestCase.java from the rat report. Please fix the license and prepare a new build. Ciao Henning On Fri, 2008-12-12 at 07:38 -0800, Nathan Bubna wrote: > Ok, there were no complaints about the latest 1.6.1 test build, so it > is time to vote: > > The test build candidate for release is still available here: > http://people.apache.org/~nbubna/velocity/engine/1.6.1/ > > Please vote regarding your support for releasing this test build as > Velocity Engine 1.6.1: > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > The voting period is typically 72 hours, putting its close time as > roughly 7am PST on Mon, Dec 15th. Vote early and vote often! :) > > On Fri, Dec 5, 2008 at 9:58 AM, Nathan Bubna wrote: > > if you didn't notice, a vararg method reflection bug (VELOCITY-651) > > was found shortly after we got 1.6 released. it is now fixed, and i > > think we need to do a bug fix release for it. it's not the sort of > > thing that should wait around for a 1.7 release. so, here's a test > > build for 1.6.1. > > > > http://people.apache.org/~nbubna/velocity/engine/1.6.1/ > > > > please give it a look and a test. i'll probably call for a vote on > > Tuesday. i'm aiming for a Fri (12/12) release. > > > > thanks, > > nathan > > > > - > To unsubscribe, e-mail: private-unsubscr...@velocity.apache.org > For additional commands, e-mail: private-h...@velocity.apache.org > -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux Mail: henn...@schmiedehausen.org-- Consultant, Architect, Developer Web: http://henning.schmiedehausen.org/ - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release VelocityTools 2.0-beta3
+1 :-) On Sun, 2008-11-30 at 20:22 -0800, Nathan Bubna wrote: > Drawing the [VOTE] thread to Henning's attention... :) > > On Sun, Nov 30, 2008 at 2:21 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Ok, Will said the new test build works for him; it is still available here: > > http://people.apache.org/~nbubna/velocity/tools/2.0-beta3/ > > > > Please vote regarding your support for releasing this new test build as > > VelocityTools 2.0-beta3: > > > > [ ] +1 Let's do it > > [ ] +0 Have fun; i don't care. > > [ ] -0 Not sure about this, but i won't stop you. > > [ ] -1 No, because __ > > > > The voting period is typically 72 hours, putting its close time as > > roughly 2pm PST on Wednesday, Dec 3. Though if i get 3 +1s before > > then, i'll end it early. It's just a beta, after all. :) > > > > My vote is, again, +1 > > > > On Sun, Nov 30, 2008 at 9:01 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > >> Ok, i've accepted Will's veto and am changing my vote to -1, so here's > >> the result for the record: > >> > >> -1 > >> Nathan Bubna > >> Will Glass-Husain > >> > >> On Sun, Nov 30, 2008 at 7:49 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > >>> Thanks, Will. I actually feel like Adrian (or someone) reported this > >>> too, but i forgot about it, since it's been working fine for me. > >>> Well, i'll scrap this one and try to fix that. I guess this won't be > >>> going out in the same site update as Velocity Engine 1.6. > >>> > >>> On Sat, Nov 29, 2008 at 9:38 PM, Will Glass-Husain > >>> <[EMAIL PROTECTED]> wrote: > -1. Doesn't build. see error report below. > > WILL > > > C:\Documents and Settings\wglass\Desktop\velocity-tools-2.0-beta3-src>ant > Buildfile: build.xml > > clean: > [delete] Deleting directory C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\build > [delete] Deleting directory C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\dist > > clean-examples: > > simple-example: > > example-clean: > > showcase-example: > > example-clean: > > struts-example: > > example-clean: > > test.clean: > > prepare.compile: > [mkdir] Created dir: C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\build > [mkdir] Created dir: C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\build\classes > [mkdir] Created dir: C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\dist > > base-download: > > commons-collections-download: > > http-m1-download: > > do-http-m1-download: > [get] Getting: > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-collections/jars/commons-collections-3.2.jar > [get] To: C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\lib\commons-collections-3.2.jar > [get] Error opening connection java.io.FileNotFoundException: > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-collecti > ons/jars/commons-collections-3.2.jar > [get] Error opening connection java.io.FileNotFoundException: > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-collecti > ons/jars/commons-collections-3.2.jar > [get] Error opening connection java.io.FileNotFoundException: > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-collecti > ons/jars/commons-collections-3.2.jar > [get] Can't get > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-collections/jars/commons-collections-3.2.jarto > C:\Doc > uments and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\lib\commons-collections-3.2.jar > > BUILD FAILED > C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\build.xml:104: The > following error occurred while executing > this line: > C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\download.xml:40: The > following error occurred while executin > g this line: > C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\download.xml:209: > The > following error occurred while executi > ng this line: > C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\download.xml:121: > The > following error occurred while executi > ng this line: > C:\Documents and > Settings\wglass\Desktop\velocity-tools-2.0-beta3-src\download.xml:132: > Can't > get http://mirrors.ibiblio.org/pub/m > irrors/maven2/commons-collections/jars/commons-collections-3.2.jar to > C:\Documents and Settings\wglass\Desktop\velocity-tools-2.0- > beta3-src\lib\commons-collections-3.2.jar > > Total time: 1 second > > > > >>>
Re: [VOTE] Release Velocity Engine 1.6
RAT looks good, builds for me with JDK 1.6.0_10 on i386 Linux (Fedora).
+1
Ciao
Henning
On Fri, 2008-11-28 at 07:08 -0800, Nathan Bubna wrote:
> Ok, there were no complaints about the current test build that were
> worth generating a new test build and delaying this (IMO), so i'm
> moving on to a vote.
>
> The test build candidate for release is still available here:
> http://people.apache.org/~nbubna/velocity/engine/1.6/
>
> Please vote regarding your support for releasing this new test build as
> Velocity Engine 1.6:
>
> [ ] +1 Let's do it
> [ ] +0 Have fun; i don't care.
> [ ] -0 Not sure about this, but i won't stop you.
> [ ] -1 No, because __
>
> The voting period is typically 72 hours, putting its close time as
> roughly 7am PST on Monday, Dec 1st. If the vote passes, I'll push
> this to the mirrors and change the web site and get Henning to deploy it.
> With luck i'll be able to announce it by Wed.
>
> On Fri, Nov 21, 2008 at 11:38 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> > ok folks, i think the time has come; here's a build for Engine 1.6:
> >
> > http://people.apache.org/~nbubna/velocity/engine/1.6/
> >
> > please kick the tires and report any and all nitpicks soon. PLEASE
> > try it out and look for problems. (yes, i am begging!) assuming no
> > one sees any problems, i'll call for a release vote next friday.
> >
> > thanks,
> > nathan
> >
> > p.s. this release should rock; here's a rough list of new things in
> > this release:
> >
> > Major memory and speed performance improvements
> > varargs support for object method calls
> > #evaluate( $stringthatcontainsvtl )
> > #define( $body ) for VTL blocks as references #end
> > #break for ending #foreach loops prematurely
> > Static utility methods via context.put("Math", Math.class)
> > fixes for many annoying little syntax/parsing bugs
> > #parse( "mymacros.vm" )
> > CommonsLogLogChute, ServletLogChute
> > Fixed and much improved StringResourceLoader
> > velocimacro.max.depth
> > programmatic inclusion of macro libraries
> > can now call fixed-length list methods on arrays
> > $velocityHasNext for #foreach loops
> > configurable connection timeout for URLResourceLoader
> > Uberspect chainability and link-ability
> > consistent, correct line numbers and macro/template stacks in logs and
> > exceptions
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux
Mail: [EMAIL PROTECTED]-- Consultant, Architect, Developer
Web: http://henning.schmiedehausen.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity 1.6 test build available
I plan on testing this today or tomorrow.
Ciao
Henning
On Mon, 2008-11-24 at 16:50 -0800, Nathan Bubna wrote:
> Ok, updated again with fix for VELOCITY-649. Same address, same plan.
> If Byron (or anyone else) finds more bugs tomorrow, then i'll start
> pushing the schedule back. :)
>
> On Mon, Nov 24, 2008 at 12:39 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> > An updated test build including the fix for VELOCITY-644 and a couple
> > minor test/build tweaks is now up at:
> >
> > http://people.apache.org/~nbubna/velocity/engine/1.6/
> >
> > I still plan to call for a release vote on friday. Please check this
> > out before then, so you can vote promptly. Thanks!
> >
> > On Fri, Nov 21, 2008 at 11:38 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> >> ok folks, i think the time has come; here's a build for Engine 1.6:
> >>
> >> http://people.apache.org/~nbubna/velocity/engine/1.6/
> >>
> >> please kick the tires and report any and all nitpicks soon. PLEASE
> >> try it out and look for problems. (yes, i am begging!) assuming no
> >> one sees any problems, i'll call for a release vote next friday.
> >>
> >> thanks,
> >> nathan
> >>
> >> p.s. this release should rock; here's a rough list of new things in
> >> this release:
> >>
> >> Major memory and speed performance improvements
> >> varargs support for object method calls
> >> #evaluate( $stringthatcontainsvtl )
> >> #define( $body ) for VTL blocks as references #end
> >> #break for ending #foreach loops prematurely
> >> Static utility methods via context.put("Math", Math.class)
> >> fixes for many annoying little syntax/parsing bugs
> >> #parse( "mymacros.vm" )
> >> CommonsLogLogChute, ServletLogChute
> >> Fixed and much improved StringResourceLoader
> >> velocimacro.max.depth
> >> programmatic inclusion of macro libraries
> >> can now call fixed-length list methods on arrays
> >> $velocityHasNext for #foreach loops
> >> configurable connection timeout for URLResourceLoader
> >> Uberspect chainability and link-ability
> >> consistent, correct line numbers and macro/template stacks in logs and
> >> exceptions
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-554) Velocity sources and javadocs missing in the maven repository
[ https://issues.apache.org/jira/browse/VELOCITY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643114#action_12643114 ] Henning Schmiedehausen commented on VELOCITY-554: - So now we have -m1-downloads and -m2-downloads, but this is actually not what I meant. I meant bundling the maven-wagon tasks with Velocity to use them to download the jars (and use things like mirrors etc.) > Velocity sources and javadocs missing in the maven repository > - > > Key: VELOCITY-554 > URL: https://issues.apache.org/jira/browse/VELOCITY-554 > Project: Velocity > Issue Type: New Feature > Components: Build >Affects Versions: 1.5 >Reporter: Aliaksandr Radzivanovich > Fix For: 1.6 > > Attachments: VELOCITY-554-2.patch, VELOCITY-554_download.patch > > > It is really annoying when popular projects like Apache Velocity do not > provide their sources and javadocs to the Maven repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-466) Look into maven plugins for ant to use automatic deployment to maven repositories
[ https://issues.apache.org/jira/browse/VELOCITY-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634027#action_12634027 ] Henning Schmiedehausen commented on VELOCITY-466: - You are more than welcome to "forward port" the plugins under http://svn.apache.org/viewvc/velocity/site/tools/ to the current minor version 2.0.9 (or .10). They run reasonably well under 2.0.6 so it shouldn't be too hard to get them to run under 2.0.9 I am looking forward to your report about the stability of the Maven core. > Look into maven plugins for ant to use automatic deployment to maven > repositories > - > > Key: VELOCITY-466 > URL: https://issues.apache.org/jira/browse/VELOCITY-466 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 1.5 >Reporter: Henning Schmiedehausen >Assignee: Henning Schmiedehausen >Priority: Minor > Fix For: 1.6 > > > there are maven plugins that can be driven by ant to automatically deploy the > velocity builds to the maven repositories (suggested by Thomas Minor, thanks) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-466) Look into maven plugins for ant to use automatic deployment to maven repositories
[ https://issues.apache.org/jira/browse/VELOCITY-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634010#action_12634010 ] Henning Schmiedehausen commented on VELOCITY-466: - Sorry, but as long as I am on the PMC, I will veto any attempts to move to an "exclusive maven based build" until maven has proven to be stable for at least two minor versions (2.1, 2.2, 2.3 etc.) in a row. Feel free to submit an updated POM but expect me to - veto any file shuffling for the sake of the build - veto any proposal to change the official release builds to use maven - veto anything that would risk destabilizing the ant build - veto anything that is proven to be unstable in the long run (i.e. not locking down *any* version of a plugin or dependency completely) in the POM. Sorry, been there, done that, got the scars to prove it. Velocity uses ant as its official build system, everything else is bonus. What I would very much appreciate is a proposal that would allow the ant build to use the ant-wagon tasks to deploy release and test artifacts to the maven repositories. That is what this ticket is all about. Just being "pro Maven" doesn't help much. I am "pro stability". > Look into maven plugins for ant to use automatic deployment to maven > repositories > - > > Key: VELOCITY-466 > URL: https://issues.apache.org/jira/browse/VELOCITY-466 > Project: Velocity > Issue Type: Improvement > Components: Build > Affects Versions: 1.5 > Reporter: Henning Schmiedehausen >Assignee: Henning Schmiedehausen >Priority: Minor > Fix For: 1.6 > > > there are maven plugins that can be driven by ant to automatically deploy the > velocity builds to the maven repositories (suggested by Thomas Minor, thanks) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: velocity-site sucks
Hmm, I seem to do something wrong... :-) % slogin velocity.zones.apache.org Last login: Tue Sep 23 01:10:16 2008 from adsl-76-200-189 Sun Microsystems Inc. SunOS 5.10 Generic January 2005 bash-3.00$ newgrp velocity bash-3.00$ ~velocity/bin/build_velocity_site.sh > /tmp/logfile 2>&1 bash-3.00$ tail -10 /tmp/logfile scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Tue Sep 23 01:16:38 GMT+00:00 2008 [INFO] Final Memory: 8M/66M [INFO] bash-3.00$ works for me. What errors exactly do you get? Maybe I have some env variables set differently from you. I could sudo to your account if you don't mind. Ciao Henning On Mon, 2008-09-22 at 17:26 -0700, Nathan Bubna wrote: > this still sucks... henning, do you have any time to help me with > this? even if you can just update the public site. the changes are > checked in, i just can't get > > newgrp velocity > /export/home/velocity/bin/build_velocity_site.sh > > to run for me on the zone. > > On Mon, Jul 7, 2008 at 11:42 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Ok, in a fit of procrastinating what i should really work on this > > morning, i thought i'd try and do a quick update of the site to show > > the Tools 2.0-beta1 release, and thus ensure i can update the site on > > my new laptop, prior to finalizing (hopefully) the 2.0-beta2 release. > > Unfortunately, i can't build the site tools. It looks like the > > velocity-site-news plugin is not keeping pace with plexus: > > > > ... > > C:\java\apache\velocity\site\tools\velocity-site-news-plugin\target\generated-sources\modello\org\apache\velocity\site\news\model\ > > io\xpp3\NewsXpp3Reader.java:[18,31] cannot find symbol > > symbol : class ReaderFactory > > location: package org.codehaus.plexus.util > > ... > > > > now, this was just a matter of telling the pom to use some older > > version of plexus and in theory i shouldn't even need to have to site > > stuff all working on my computer, but i feel better about checking > > stuff in if i can try it locally. so, i tweaked the > > velocity-site-news-plugin pom, got the site tools to all build and was > > able to go to the site directory and run the site target successfully. > > but then, the site:run target failed. frustrated i decided to go > > ahead and check in my changes and just try building and deploying the > > site from velocity.zones.apache.org. I followed the instructions and > > all seemed to go well until the build_velocity_site.sh script failed > > when trying to actually deploy the updated site: > > > > [INFO] [site:deploy] > > scpexe://people.apache.org/www/velocity.apache.org - Session: Opened > > Using private key: /export/home/velocity/.ssh/id_rsa > > Executing command: /bin/bash -c 'ssh -i > > /export/home/velocity/.ssh/id_rsa -o "BatchMode yes" > > [EMAIL PROTECTED] "mkdir -p /w > > ww/velocity.apache.org/."' > > > > Permission denied (publickey,keyboard-interactive). > > > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected > > [INFO] > > > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] Error uploading site > > > > Embedded error: Error performing commands for file transfer > > Exit code 255 - Permission denied (publickey,keyboard-interactive). > > > > > > this is far from the first time i've seen this. in fact, i recall > > spending much time fighting this same error in the past. i can't even > > remember if i succeeded though. either way, i'm sick of the maven > > site building headaches. what should be a fairly simple task has been > > an ordeal *for YEARS now*! the current process is brittle, unwieldy > > and worst of all, unmaintained. in contrast, there is the site > > process for VelocityTools: > > > > - uses DVSL (VTL-based, encourages DVSL maintenance) > > - deploy process is just: > > ant publish.docs > > ssh @people.apache.org > >cd /www/velocity.apache.org/tools/devel (or release/) > >unzip -o ../docs.zip > > - and it works! no headaches! > > > > it's simple, low-maintenance, and doesn't make me want to throw > > things. granted, it may not have all the snazzy features Maven > > provides, but we're barely taking advantage of them anyway. so, > > consider this my warning that i intend to ditch this whole > > velocity-site thing. if any of you think this is a bad idea, by all > > means, please step up and mai
Re: velocity-site sucks
Yep, taking a look now. Ciao Henning On Mon, 2008-09-22 at 17:26 -0700, Nathan Bubna wrote: > this still sucks... henning, do you have any time to help me with > this? even if you can just update the public site. the changes are > checked in, i just can't get > > newgrp velocity > /export/home/velocity/bin/build_velocity_site.sh > > to run for me on the zone. > > On Mon, Jul 7, 2008 at 11:42 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Ok, in a fit of procrastinating what i should really work on this > > morning, i thought i'd try and do a quick update of the site to show > > the Tools 2.0-beta1 release, and thus ensure i can update the site on > > my new laptop, prior to finalizing (hopefully) the 2.0-beta2 release. > > Unfortunately, i can't build the site tools. It looks like the > > velocity-site-news plugin is not keeping pace with plexus: > > > > ... > > C:\java\apache\velocity\site\tools\velocity-site-news-plugin\target\generated-sources\modello\org\apache\velocity\site\news\model\ > > io\xpp3\NewsXpp3Reader.java:[18,31] cannot find symbol > > symbol : class ReaderFactory > > location: package org.codehaus.plexus.util > > ... > > > > now, this was just a matter of telling the pom to use some older > > version of plexus and in theory i shouldn't even need to have to site > > stuff all working on my computer, but i feel better about checking > > stuff in if i can try it locally. so, i tweaked the > > velocity-site-news-plugin pom, got the site tools to all build and was > > able to go to the site directory and run the site target successfully. > > but then, the site:run target failed. frustrated i decided to go > > ahead and check in my changes and just try building and deploying the > > site from velocity.zones.apache.org. I followed the instructions and > > all seemed to go well until the build_velocity_site.sh script failed > > when trying to actually deploy the updated site: > > > > [INFO] [site:deploy] > > scpexe://people.apache.org/www/velocity.apache.org - Session: Opened > > Using private key: /export/home/velocity/.ssh/id_rsa > > Executing command: /bin/bash -c 'ssh -i > > /export/home/velocity/.ssh/id_rsa -o "BatchMode yes" > > [EMAIL PROTECTED] "mkdir -p /w > > ww/velocity.apache.org/."' > > > > Permission denied (publickey,keyboard-interactive). > > > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected > > [INFO] > > > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] Error uploading site > > > > Embedded error: Error performing commands for file transfer > > Exit code 255 - Permission denied (publickey,keyboard-interactive). > > > > > > this is far from the first time i've seen this. in fact, i recall > > spending much time fighting this same error in the past. i can't even > > remember if i succeeded though. either way, i'm sick of the maven > > site building headaches. what should be a fairly simple task has been > > an ordeal *for YEARS now*! the current process is brittle, unwieldy > > and worst of all, unmaintained. in contrast, there is the site > > process for VelocityTools: > > > > - uses DVSL (VTL-based, encourages DVSL maintenance) > > - deploy process is just: > > ant publish.docs > > ssh @people.apache.org > >cd /www/velocity.apache.org/tools/devel (or release/) > >unzip -o ../docs.zip > > - and it works! no headaches! > > > > it's simple, low-maintenance, and doesn't make me want to throw > > things. granted, it may not have all the snazzy features Maven > > provides, but we're barely taking advantage of them anyway. so, > > consider this my warning that i intend to ditch this whole > > velocity-site thing. if any of you think this is a bad idea, by all > > means, please step up and maintain the velocity-site mess. i don't > > think anything less than that will change my mind, and it's doubtful > > whether even that would change it for long. i'm not sure when i'll > > get to making the change; i've little doubt that it will be more work > > than i imagine (especially figuring out what to do with those APT > > files); and i'm sure it won't be fun. but consider this my notice > > that i will no longer waste my time with this convoluted, > > temperamental Maven-crazy velocity-site stuff. > > > > p.s. help is welcome, and no one is allowed to complain about the lack > > of site updates unless they help, one way or another. ;-) > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Engine 1.6-beta1 test build 2
rat is clean, checksums and signature are ok. builds on Java 1.6_07 x86_64 on Linux with ant 1.7.1 +1 from me Ciao Henning On Tue, 2008-09-16 at 08:59 -0700, Nathan Bubna wrote: > There was no negative feedback on the 2nd test build (no feedback at all > actually), so i'm moving on to a vote again. > > The test build is still available here: > http://people.apache.org/~nbubna/velocity/engine/1.6-beta1/ > > Please vote regarding your support for releasing this new test build as > Velocity Engine 1.6-beta1: > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > The voting period is typically 72 hours, putting its close time as > roughly 9am PST on Friday, Sep 19th. If the vote passes, I'll push > this to the mirrors and perhaps begin struggling to update the web site that > afternoon. Of course, recent history indicates that there's really no > telling when i'll actually succeed with that last part and be able to > announce the release. > > On Wed, Sep 10, 2008 at 11:15 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > The last test build for 1.6-beta1 failed due to some missing license > > headers. > > It's been replaced by a new build for Engine 1.6-beta, this one based > > on revision 693911. > > > > http://people.apache.org/~nbubna/velocity/engine/1.6-beta1/ > > > > please kick the tires and report any other nitpicks soon. you don't > > have to wait for the CfV to form an opinion on this. :) anyway, > > assuming no one > > sees any problems, i'll call for another release vote on Friday or > > Saturday, aiming for a release on Monday or Tuesday. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity Engine 1.6-beta1
-0 rat reports some files missing license headers: ./src/java/org/apache/velocity/util/introspection/LinkingUberspector.java ./src/test/org/apache/velocity/test/util/introspection/ChainedUberspectorsTestCase.java When these are fixed, I'm +1 on the beta. signature checks out, md5 checks out. Builds with ant 1.7.1 on Linux x86_64 using Sun JDK 1.6.0_07 There is some odd output in some of the test cases, don't know whether this is intended or not (it shows part of the ASL for an SQL statement) Ciao Henning On Mon, 2008-09-08 at 10:24 -0700, Nathan Bubna wrote: > There was no negative feedback on the test build (no feedback at all > actually), so i'm moving on to a vote... > > The test build is still available here: > http://people.apache.org/~nbubna/velocity/engine/1.6-beta1/ > > Please vote regarding your support for releasing this test build as > Velocity Engine 1.6-beta1: > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > The voting period is typically 72 hours, putting its close time as > roughly 10am PST on Thursday, Jul 3rd. If the vote passes, I'll push > this to the mirrors and begin struggling to update the web site that > afternoon. Of course, recent history indicates that there's really no > telling when i'll actually succeed with that last part and be able to > announce the release. > > On Tue, Sep 2, 2008 at 9:07 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > ok folks, here's a build for Engine 1.6-beta. > > > > http://people.apache.org/~nbubna/velocity/engine/1.6-beta1/ > > > > please kick the tires and report any nitpicks soon. assuming no one > > sees any problems, i'll call for a release vote in a few days. with > > luck, that vote will close early next week, and i can push this > > release out. > > > > thanks, > > nathan > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: download.cgi broken
It works again now, the mirrors have picked up download.cgi. I will have lots of free time after mid-August; taking on the various custom plugins to build the velocity site and bring then into mainline maven is one of the things. :-) Ciao Henning On Mon, 2008-07-14 at 21:02 -0700, Will Glass-Husain wrote: > I'm looking at it, but don't see anything obvious. > > Site guru Henning-- are you around? > > WILL > > > On Mon, Jul 14, 2008 at 7:30 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > ok, so i somehow managed to break > > > > http://velocity.apache.org/download.cgi > > > > in my attempt at a manual update of the site to add Tools 2.0-beta2. > > i've tried a few things to fix it, but no dice yet. so for now i > > changed the news.html and news.rss to point directly to a working > > download: > > > > http://www.apache.org/dyn/closer.cgi/velocity-tools/2.0-beta2 > > > > still, the main download page really needs fixing ASAP, and i'm out of > > ideas for the moment. can anyone see the problem? i did contact > > [EMAIL PROTECTED], but i haven't heard anything back yet. i'd love > > to fix this before announcing the beta2 release and drawing any extra > > attention to the site. > > > > help! > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: download.cgi broken
Hm, it is no longer a cgi but a copy of download.html ... strange. I copied a download.cgi file (which is really only a two-liner) back in place; it should work again as soon as the mirrors catch up. Ciao Henning On Mon, 2008-07-14 at 21:02 -0700, Will Glass-Husain wrote: > I'm looking at it, but don't see anything obvious. > > Site guru Henning-- are you around? > > WILL > > > On Mon, Jul 14, 2008 at 7:30 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > ok, so i somehow managed to break > > > > http://velocity.apache.org/download.cgi > > > > in my attempt at a manual update of the site to add Tools 2.0-beta2. > > i've tried a few things to fix it, but no dice yet. so for now i > > changed the news.html and news.rss to point directly to a working > > download: > > > > http://www.apache.org/dyn/closer.cgi/velocity-tools/2.0-beta2 > > > > still, the main download page really needs fixing ASAP, and i'm out of > > ideas for the moment. can anyone see the problem? i did contact > > [EMAIL PROTECTED], but i haven't heard anything back yet. i'd love > > to fix this before announcing the beta2 release and drawing any extra > > attention to the site. > > > > help! > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.4 (take two)
Just give us a few hours/days to try it out before CfV. This avoids having to stop CfVs. :-) Best regards Henning Nathan Bubna schrieb: > On Nov 16, 2007 1:00 PM, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: >> "Antonio Petrelli" <[EMAIL PROTECTED]> writes: >> >>> 2007/11/16, Nathan Bubna <[EMAIL PROTECTED]>: >>>> hmm. do you think this is something worth re-rolling the release? >>> It's really annoying for maven-based software (like Struts 2) that use >>> Velocity Tools. >>> In Struts 2 it was necessary to exclude the servlet-api 2.3 to make it work. >>> And it is wrong: it has to be "provided" since it is usually provided >>> by containers. >> ^it has to be^it should be >> >> apart from that, I fully agree. The dependency should be 'provided'. >> >> Nathan: I am actually -1 to releasing with "compile" dependency for >> the servlet api. Antonio is right here. > > ok, here we go again... > >> BTW: You can put out the RCs for consideration in your home directory >> without formal CfV. We only need a CfV if that stuff goes into an >> "official" repository or location. > > i know; that's been the hope with each CfV. > >> Best regards >> Henning >> >> -- >> Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, >> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person >> Open Source Consulting, Development, Design| Velocity - Turbine guy >> >> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 >> Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen >> >>"...it's good to be a lunatic..." -- 10th doctor >> >> - >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine "Save the cheerleader. Save the world." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.4
+1. Thanks for putting this out. Nathan Bubna schrieb: > Ok, folks. I believe it's time to wrap up VelocityTools 1.x and move > on. This is the last planned release in the 1.x series. Since i > really don't think anyone has other changes waiting in the wings for > the release, i went ahead and rolled the test build. Please test > thoroughly, so just maybe it can really be the last one without any > point releases for typos or build problems. :) > > The test build for this release is available at: > http://people.apache.org/~nbubna/velocity/tools/1.4/ > > Please vote regarding your support for releasing this test build as > VelocityTools 1.4: > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > The voting period is typically 72 hours, putting its close time as > roughly 5pm PST on Saturday, Nov 17th. If i do not find time amidst > chores that day to finish the release process, then i will do so > first thing Monday morning (assuming the vote passes), with the hope > that we can announce the release Tuesday morning. > > My vote is +1 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine "Save the cheerleader. Save the world." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Texen patches coming
Hi, on my laptop, I have a number of Texen refactorings sitting for ages (since AC EU 07 to be exact), which I never committed. I took the time at AC US to finish these and will start to apply them to the Texen repo shortly. This brings the Texen codebase to the same level as Anakia. I am aware of the various things that have been going on in the meantime and the FileLRU patches and I try to preserve them. These roll the Texen Ant Tasks into actual unit tests, which will also allow the patches for multifile etc. to be changed to real ant tasks. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine "Save the cheerleader. Save the world." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-443) Velocity 1.4 does not support Iterable collections.
[ https://issues.apache.org/jira/browse/VELOCITY-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533343 ] Henning Schmiedehausen commented on VELOCITY-443: - That implies that iterator() always returns an Iterator object which might lead to hard-to-find ClassCastExceptions. I'd appreciate a catch (ClassCastException ) with a meaningful error message. Apart from that: Nice. > Velocity 1.4 does not support Iterable collections. > --- > > Key: VELOCITY-443 > URL: https://issues.apache.org/jira/browse/VELOCITY-443 > Project: Velocity > Issue Type: Improvement >Affects Versions: 1.4 > Environment: Java 5 >Reporter: Peter Lawrey >Assignee: Nathan Bubna >Priority: Minor > Fix For: 1.6 > > > In the new for loop in Java 5 e.g. > for(Object obj: iterable) > the collection iterated only needs to be of type Iterable > However, In Velocity a foreach loop must be either a Collection or a Map but > cannot be just an Iterable. > Suggestion, support Iterable containers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved DBF-1. -- Resolution: Fixed Fix Version/s: 1.1 Patch applied with minor corrections. Thanks Matthew! > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Assignee: Henning Schmiedehausen >Priority: Minor > Fix For: 1.1 > > Attachments: default_imageincludes.txt, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned DBF-1: Assignee: Henning Schmiedehausen > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Assignee: Henning Schmiedehausen >Priority: Minor > Fix For: 1.1 > > Attachments: default_imageincludes.txt, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523061 ] Henning Schmiedehausen commented on DBF-1: -- I think this patch is worth applying if it gets properly documented. Could you add a description "how it works" to the notes section of the manual? There is a section called "Referencing images", I could imagine a section "Selecting images for inclusion". As I understand your patch, this is strictly optional, so if I don't have a .images file, then the behaviour is as before, isn't it? > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > Attachments: default.imageincludes, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBF-1) Copy images based on type and target
[ https://issues.apache.org/jira/browse/DBF-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518657 ] Henning Schmiedehausen commented on DBF-1: -- This is a nice idea. Problem might be that now a docbook author must keep track which image to include where for all types of target media in multiple files. I will look into this over the weekend. Thanks for the patch. > Copy images based on type and target > > > Key: DBF-1 > URL: https://issues.apache.org/jira/browse/DBF-1 > Project: DocBook Framework > Issue Type: Improvement > Environment: Ubuntu Feisty >Reporter: Matthew Koch >Priority: Minor > Attachments: default.imageincludes, imageincludes.patch > > > I noticed in the DBF documentation that there is a TODO item to not blindly > copy images. Would an acceptable solution be to add an 'includesfile' to the > fileset for the copy task for images based on the target (and if desirable on > the type)? For example, for the 'pdf' type of the 'manual' target there > could be a file called manual.pdf.image.includes that would specify which > images to include/exclude. I haven't tested the behavior of the includesfile > attribute much, so it may be necessary to have a default includesfile with > "images/**". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release DVSL 1.0
+1. Thanks Claude for stepping up here. On Mon, 2007-07-02 at 01:26 +0200, Claude Brisson wrote: > Hi people. > > Here is the vote to release DVSL 1.0. > Since there hasn't been any significant code change but cosmetic ones > since quite a long time, there is probably no need to run through the > whole alpha/beta/RC process. > > [ ] +1 Let's do it > [ ] +0 Have fun; i don't care. > [ ] -0 Not sure about this, but i won't stop you. > [ ] -1 No, because __ > > +1 > > ah, and I'm supposed to give some delay to the vote - let's say roughly > four days... > > @+ > > Claude > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release VelocityTools 2.0-alpha1 (Take 2)
Glad it passed. Just a weekend is a bit short.
Best regards
Henning
On Mon, 2007-07-02 at 09:08 -0700, Nathan Bubna wrote:
> The vote has passed:
>
> +1 Nathan Bubna, Will Glass-Husain, Claude Brisson
>
> No other votes were recorded.
>
>
> On 6/28/07, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> > Ok, here goes again. The problem with the source build has been fixed
> > and my refactorings from this morning are now included. Sorry that we
> > have to do this again, but here goes:
> >
> > The new test build for this release is once again available at:
> > http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/
> >
> > Check out the release artifacts, play with an example, and vote! :)
> >
> > [ ] +1 Let's do it
> > [ ] +0 Have fun; i don't care.
> > [ ] -0 Not sure about this, but i won't stop you.
> > [ ] -1 No, because __
> >
> > The voting period is typically 72 hours, but i won't wrap it up until
> > the morning of Monday, July 2 at the earliest. If there aren't enough +1s
> > and no -1s, then the vote will stay open until either i'm tired of
> > waiting or all PMC members have voted. :)
> >
> > My vote is +1
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux,
|gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Macro Improvement - GSCO
gt; > > * getVelocimacro (do not remove the synchronized block!) > > > * initVelocimacro > > > * addVelocimacro > > > > > > This is hopefully enough to get you going. Write a small harness to > > > test your code (load a template, parse it, render it) and test a few > > > very simple templates under the debugger. This should give you an idea > > > how inline macros work. Try again with a macro library (configured in > > > properties) to understand the difference. Look at the setFromLibrary() > > > methods in the MacroEntry class. > > > > > > Find out, what the Twonk is good for. ;-) > > > > > >Best regards > > >Henning > > > > > > -- > > > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, > > >|gls > > > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person > > > |eau > > > Open Source Consulting, Development, Design| Velocity - Turbine guy > > > |rwc > > > > > > |m k > > > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 > > > |a s > > > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning > > > Schmiedehausen |n > > > > > > "Save the cheerleader. Save the world." > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DVSL site generation
2) jaxen:jaxen:jar:1.1.1 > > 4) junit:junit:jar:4.3.1 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=junit -DartifactId=junit \ > -Dversion=4.3.1 -Dpackaging=jar -Dfile=/path/to/file > > Path to dependency: > 1) org.apache.dvsl:dvsl:pom:1.0-SNAPSHOT > 2) junit:junit:jar:4.3.1 > > 5) commons-lang:commons-lang:jar:2.3 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=commons-lang > -DartifactId=commons-lang \ > -Dversion=2.3 -Dpackaging=jar -Dfile=/path/to/file > > Path to dependency: > 1) org.apache.dvsl:dvsl:pom:1.0-SNAPSHOT > 2) commons-lang:commons-lang:jar:2.3 > > -- > 5 required artifacts are missing. > > for artifact: > org.apache.dvsl:dvsl:pom:1.0-SNAPSHOT > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anakia / Texen deprecation?
Carlos moved them back and I just put the gpg keys in. So we are good to go. Best regards Henning Will Glass-Husain schrieb: > Yes. > > Are we satisfied with the jar/repo location issue? If everything is > stable, I'll send an announcement. > > WILL > > On 5/2/07, *Henning P. Schmiedehausen * <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I just noted that the classes in the velocity engine trunk are not yet > deprecated. I assume that we are waiting for the Anakia/Texen > announcement? > > Best regards > Henning > > -- > Henning P. Schmiedehausen -- [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> | J2EE, Linux, |gls > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache > person |eau > Open Source Consulting, Development, Design| Velocity - Turbine > guy |rwc > > |m > k > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB > 7350 |a s > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning > Schmiedehausen |n > >"Save the cheerleader. Save the world." > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > > > -- > Forio Business Simulations > > Will Glass-Husain > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > www.forio.com <http://www.forio.com> -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine "Save the cheerleader. Save the world." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anakia and texen in the repository
Yes, sure. Best regards Henning Will Glass-Husain schrieb: > Henning, > > If consensus is reached between you and Carlos, could you post a summary > on the dev list on process/location changes for the next release? I > know the discussion has been public, but a paragraph or two summary > would be very helpful for those of us who are not Maven mavens. > > best, > WILL > > On 5/3/07, *Henning Schmiedehausen* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi Carlos, > > I will put in the signatures shortly. > > For the engine, we have extension from the Apache POM already in SVN, > for the others it will follow too before we release. > > Best regards > Henning > > > Carlos Sanchez schrieb: > > ok, so you are going to use those groups and put the artifacts only in > > the m2 repo from now on, right? > > > > I've rename them, you still have to add the PGP signatures to jars > and poms > > > > for next versions I'd suggest you to extend the apache parent pom to > > inherit some common information and reduce the size of your poms. > > http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom > > > > > > On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > >> Thank you for the clarification, Carlos. > >> > >> Can you fix the repo to use the new id's (org.apache.texen and > >> org.apache.anakia) by renaming the directories back and remove the > >> velocity-anakia and velocity-texen groups or can we do this > ourselves? > >> > >> Best regards > >> Henning > >> > >> > >> Carlos Sanchez schrieb: > >> > unfortunately there's no tooling for policy enforcement in the > repo > >> > and we are force to deal with issues like this after things are > >> > deployed and before they get propagated to the mirrors. It's > not the > >> > best solution, but is the only one right now. > >> > And I'm trying to solve future problems based on past experiences. > >> > > >> > The m1 and m2 repos are automatically converted to each other, > so you > >> > only need to deploy to one of them. > >> > > >> > Policies are the same, you can use old groupIds or use new ones > under > >> > org.apache.* > >> > > >> > You can put under m1 repo org.apache.velocity groupid, no > problem with > >> > that. For convenience people usually deploy with ant or m1 to > the m1 > >> > repo and with m2 to the m2 repo. > >> > > >> > Another different issue is the group naming convention, for me > it'd > >> > make sense that anakia and texen were under org.apache.velocity.* > >> > based on my experience and considering the explosion of groups that > >> > could happen if all subprojects start using top level groupIds. > AFAIK > >> > there's no policy about this, so that's just my suggestion. > >> > > >> > What it is a policy is that all releases must be PGP signed, > and also > >> > you have to remove the repositories/repository entry > >> > "http://people.apache.org/repo/m2-ibiblio-rsync-repository"; > from the > >> > poms as it's internal use only. > >> > > >> > Sorry for the trouble. For me it'd be also easier to forget > about it, > >> > but in the long term this is going to save problems. > >> > > >> > > >> > On 5/1/07, Henning Schmiedehausen < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > >> >> Carlos, > >> >> > >> >> please stop this. > >> >> > >> >> For maven-1, we either keep texen and anakia in the velocity > group or > >> >> drop it completely from there. That is fine with me, no more > groups, > >> >> yadda, yadda. > >> >> > >> >> However, for maven-2 we will adhere to your 'standards'. This > >> means, the > >>
Re: Anakia and texen in the repository
Hi Carlos, I will put in the signatures shortly. For the engine, we have extension from the Apache POM already in SVN, for the others it will follow too before we release. Best regards Henning Carlos Sanchez schrieb: > ok, so you are going to use those groups and put the artifacts only in > the m2 repo from now on, right? > > I've rename them, you still have to add the PGP signatures to jars and poms > > for next versions I'd suggest you to extend the apache parent pom to > inherit some common information and reduce the size of your poms. > http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom > > > On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: >> Thank you for the clarification, Carlos. >> >> Can you fix the repo to use the new id's (org.apache.texen and >> org.apache.anakia) by renaming the directories back and remove the >> velocity-anakia and velocity-texen groups or can we do this ourselves? >> >> Best regards >> Henning >> >> >> Carlos Sanchez schrieb: >> > unfortunately there's no tooling for policy enforcement in the repo >> > and we are force to deal with issues like this after things are >> > deployed and before they get propagated to the mirrors. It's not the >> > best solution, but is the only one right now. >> > And I'm trying to solve future problems based on past experiences. >> > >> > The m1 and m2 repos are automatically converted to each other, so you >> > only need to deploy to one of them. >> > >> > Policies are the same, you can use old groupIds or use new ones under >> > org.apache.* >> > >> > You can put under m1 repo org.apache.velocity groupid, no problem with >> > that. For convenience people usually deploy with ant or m1 to the m1 >> > repo and with m2 to the m2 repo. >> > >> > Another different issue is the group naming convention, for me it'd >> > make sense that anakia and texen were under org.apache.velocity.* >> > based on my experience and considering the explosion of groups that >> > could happen if all subprojects start using top level groupIds. AFAIK >> > there's no policy about this, so that's just my suggestion. >> > >> > What it is a policy is that all releases must be PGP signed, and also >> > you have to remove the repositories/repository entry >> > "http://people.apache.org/repo/m2-ibiblio-rsync-repository"; from the >> > poms as it's internal use only. >> > >> > Sorry for the trouble. For me it'd be also easier to forget about it, >> > but in the long term this is going to save problems. >> > >> > >> > On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: >> >> Carlos, >> >> >> >> please stop this. >> >> >> >> For maven-1, we either keep texen and anakia in the velocity group or >> >> drop it completely from there. That is fine with me, no more groups, >> >> yadda, yadda. >> >> >> >> However, for maven-2 we will adhere to your 'standards'. This >> means, the >> >> packages go into org.apache.texen and org.apache.anakia. That is >> the way >> >> *you* as repo people recommended it. >> >> >> >> If you have a problem with the jar being twice in your repo, well, >> maybe >> >> it is time that you get your act together and have an uniform >> policy for >> >> maven-1 and maven-2. >> >> >> >> If you do not agree here, then we will go to org.apache.texen and >> >> org.apache.anakia and drop the jars in the velocity group. I am not >> >> really interested in second guessing what you want to have and how you >> >> intend to organize it. The maven repos are a distribution >> mechanism, not >> >> a policy tool. >> >> >> >> Please rename the .bak directories. Feel free to drop the jars from >> the >> >> velocity group at your discretion, I do not really care. >> >> >> >> >> >> >> >> Best regards >> >> Henning >> >> >> >> >> >> >> >> >> >> Carlos Sanchez schrieb: >> >> > I guess these are the same as the ones in >> >> > >> http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars >> >> > >>
Re: Anakia and texen in the repository
Thank you for the clarification, Carlos. Can you fix the repo to use the new id's (org.apache.texen and org.apache.anakia) by renaming the directories back and remove the velocity-anakia and velocity-texen groups or can we do this ourselves? Best regards Henning Carlos Sanchez schrieb: > unfortunately there's no tooling for policy enforcement in the repo > and we are force to deal with issues like this after things are > deployed and before they get propagated to the mirrors. It's not the > best solution, but is the only one right now. > And I'm trying to solve future problems based on past experiences. > > The m1 and m2 repos are automatically converted to each other, so you > only need to deploy to one of them. > > Policies are the same, you can use old groupIds or use new ones under > org.apache.* > > You can put under m1 repo org.apache.velocity groupid, no problem with > that. For convenience people usually deploy with ant or m1 to the m1 > repo and with m2 to the m2 repo. > > Another different issue is the group naming convention, for me it'd > make sense that anakia and texen were under org.apache.velocity.* > based on my experience and considering the explosion of groups that > could happen if all subprojects start using top level groupIds. AFAIK > there's no policy about this, so that's just my suggestion. > > What it is a policy is that all releases must be PGP signed, and also > you have to remove the repositories/repository entry > "http://people.apache.org/repo/m2-ibiblio-rsync-repository"; from the > poms as it's internal use only. > > Sorry for the trouble. For me it'd be also easier to forget about it, > but in the long term this is going to save problems. > > > On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: >> Carlos, >> >> please stop this. >> >> For maven-1, we either keep texen and anakia in the velocity group or >> drop it completely from there. That is fine with me, no more groups, >> yadda, yadda. >> >> However, for maven-2 we will adhere to your 'standards'. This means, the >> packages go into org.apache.texen and org.apache.anakia. That is the way >> *you* as repo people recommended it. >> >> If you have a problem with the jar being twice in your repo, well, maybe >> it is time that you get your act together and have an uniform policy for >> maven-1 and maven-2. >> >> If you do not agree here, then we will go to org.apache.texen and >> org.apache.anakia and drop the jars in the velocity group. I am not >> really interested in second guessing what you want to have and how you >> intend to organize it. The maven repos are a distribution mechanism, not >> a policy tool. >> >> Please rename the .bak directories. Feel free to drop the jars from the >> velocity group at your discretion, I do not really care. >> >> >> >> Best regards >> Henning >> >> >> >> >> Carlos Sanchez schrieb: >> > I guess these are the same as the ones in >> > http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars >> > >> > - they should be only in the m1 OR m2 repo >> > - Putting them in two different groupIds is confusing >> > - if they are subprojects of velocity they should be in >> > org.apache.velocity.* >> > - missing PGP signatures >> > >> > I've moved anakia and texen out of the way for the moment (to .bak) >> > >> > >> > On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> >> wrote: >> >> Repository changed >> >> == >> >> >> >> Repository: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/ >> >> >> >> Added >> >> - >> >> [henning] org/apache/anakia >> >> [henning] org/apache/anakia/anakia >> >> [henning] org/apache/anakia/anakia/1.0 >> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar >> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5 >> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.sha1 >> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom >> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.md5 >> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.sha1 >> >> [henning] org/apache/anakia/anakia/maven-metadata.xml >> >> [henning] org/apache/anakia/anakia/maven-metadata.xml.md5 >> >> [he
Re: Anakia and texen in the repository
Hi, no, the policy set with maven-2 and also by the repo people is to use the package name of the application as it builds nicely into a tree and avoids having thousands of one-level subdirectories. This has been set in http://www.apache.org/dev/repository-faq.html (FAQ #1, they seek to phase out m1 repos). So for anakia this is org.apache.anakia, for texen it is org.apache.texen. The repo is not really about project relations and "this is part of velocity, let's have velocity somewhere". It is a machine readable tree for downloading dependencies. Best regards Henning Will Glass-Husain schrieb: > Henning, > > > FYI...Like you, I am not super happy about the jar files being moved > around (though I think all parties have the best of intentions). It'd > make sense to me to us the name in the jar path as the group id, e.g. > org.apache.anakia is anakia, or perhaps velocity-anakia. I'm following > this - but think it's best we speak with one voice so am deferring to > you for correspondence with Carlos. > > Best, WILL > > On 5/1/07, *Carlos Sanchez* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > unfortunately there's no tooling for policy enforcement in the repo > and we are force to deal with issues like this after things are > deployed and before they get propagated to the mirrors. It's not the > best solution, but is the only one right now. > And I'm trying to solve future problems based on past experiences. > > The m1 and m2 repos are automatically converted to each other, so you > only need to deploy to one of them. > > Policies are the same, you can use old groupIds or use new ones under > org.apache.* > > You can put under m1 repo org.apache.velocity groupid, no problem with > that. For convenience people usually deploy with ant or m1 to the m1 > repo and with m2 to the m2 repo. > > Another different issue is the group naming convention, for me it'd > make sense that anakia and texen were under org.apache.velocity.* > based on my experience and considering the explosion of groups that > could happen if all subprojects start using top level groupIds. AFAIK > there's no policy about this, so that's just my suggestion. > > What it is a policy is that all releases must be PGP signed, and also > you have to remove the repositories/repository entry > "http://people.apache.org/repo/m2-ibiblio-rsync-repository > <http://people.apache.org/repo/m2-ibiblio-rsync-repository>" from the > poms as it's internal use only. > > Sorry for the trouble. For me it'd be also easier to forget about it, > but in the long term this is going to save problems. > > > On 5/1/07, Henning Schmiedehausen < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Carlos, > > > > please stop this. > > > > For maven-1, we either keep texen and anakia in the velocity group or > > drop it completely from there. That is fine with me, no more groups, > > yadda, yadda. > > > > However, for maven-2 we will adhere to your 'standards'. This > means, the > > packages go into org.apache.texen and org.apache.anakia. That is > the way > > *you* as repo people recommended it. > > > > If you have a problem with the jar being twice in your repo, well, > maybe > > it is time that you get your act together and have an uniform > policy for > > maven-1 and maven-2. > > > > If you do not agree here, then we will go to org.apache.texen and > > org.apache.anakia and drop the jars in the velocity group. I am not > > really interested in second guessing what you want to have and how you > > intend to organize it. The maven repos are a distribution > mechanism, not > > a policy tool. > > > > Please rename the .bak directories. Feel free to drop the jars > from the > > velocity group at your discretion, I do not really care. > > > > > > > > Best regards > > Henning > > > > > > > > > > Carlos Sanchez schrieb: > > > I guess these are the same as the ones in > > > > http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars > > > > > > - they should be only in the m1 OR m2 repo > > > - Putting them in two different groupIds is confusing > &g
Re: question on site building/release process
all. > >> > >> We botched that part, the released jars contain a wrong pom with the > >> devel links. As I am probably the only one that would have looked at > >> this, I am guilty of neglecting oversight here. :-/ We could discuss > >> whether this is a brown-paperbag bug and fire an anakia/texen 1.0.1 > >> bug fix release with fixed POMs. > >> > >> - Update the site through velocity.zones.apache.org > <http://velocity.zones.apache.org> by building a > >> short script similar to the development site scripts (see > >> http://wiki.apache.org/velocity/RebuildSites). > >> > >> I have added scripts to the ~velocity/bin directory and deployed the > >> sites. > >> > >> Please *DO NOT* just copy the devel sites over: > >> > >> - The navigation links will be wrong (the releases are one menu > level > >> deeper) > >> - The various links in the project documentation will be wrong > (e.g. > >> trunk > >> instead of the tag) > >> > >> - Please also link > /releases/- on the > >> main > >> site, not just /releases/. I fixed this. > >> > >> >(2) Per the (somewhat out of date) instructions on the Wiki, I > uploaded > >> to > >> >the apache distro location and to the maven distro. Do I also > need to > >> >upload the files to archive.apache.org <http://archive.apache.org> ? > >> > >> Nope, that happens automatically. > >> http://archive.apache.org/dist/velocity/anakia/1.0/ > <http://archive.apache.org/dist/velocity/anakia/1.0/> has already > picked it > >> up. > >> > >> What was still missing is distributing it to the maven-2 repository. > >> I just ran this for texen and anakia, they should be picked up by > >> repo1.maven.org <http://repo1.maven.org> soon. > >> > >> This is done using > >> > >> mvn -Dfile=anakia-1.0.jar \ > >>-Drepository.id=apache.releases \ > >>-DpomFile= pom.xml \ > >> > >> > > -Durl=scpexe://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository > >> \ > >>deploy:deploy-file > >> > >> which is a bit sucky, but as we do not build using maven-2, we must > >> deploy the file by hand. It is also sensible to compare the checksums > >> in the maven repo. e.g. > >> > >> > >> > > http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5with > >> http://www.apache.org/dist/velocity/anakia/1.0/anakia-1.0.jar.md5 > <http://www.apache.org/dist/velocity/anakia/1.0/anakia-1.0.jar.md5> > >> > >> (similar for SHA1 and texen). > >> > >> If they are not the same, something went wrong! We do not want to > >> distribute different jars through maven and through dist! > >> > >> I feel a bit guilty here for not documenting the release process > >> better; for a non-maven-2 user it probably still is a bit quirky. > >> > >> > >>Best regards > >>Henning > >> > >> -- > >> Henning P. Schmiedehausen -- [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> | J2EE, > >> Linux, |gls > >> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache > >> person |eau > >> Open Source Consulting, Development, Design| Velocity - Turbine > >> guy |rwc > >> > >> |m k > >> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB > >> 7350 |a s > >> Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning > >> Schmiedehausen |n > >> > >> "Save the cheerleader. Save the world." > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> > > > >-- > >Forio Business Simulations > > >Will Glass-Husain > >[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >www.forio.com <http://www.forio.com> > > >--=_Part_78854_30603569.1177873852796-- > > -- > Henning P. Schmiedehausen -- [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> | J2EE, Linux, |gls > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache > person |eau > Open Source Consulting, Development, Design| Velocity - Turbine > guy |rwc > > |m > k > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB > 7350 |a s > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning > Schmiedehausen |n > >"Save the cheerleader. Save the world." > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > > > -- > Forio Business Simulations > > Will Glass-Husain > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > www.forio.com <http://www.forio.com> -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine "Save the cheerleader. Save the world." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anakia and texen in the repository
Carlos, please stop this. For maven-1, we either keep texen and anakia in the velocity group or drop it completely from there. That is fine with me, no more groups, yadda, yadda. However, for maven-2 we will adhere to your 'standards'. This means, the packages go into org.apache.texen and org.apache.anakia. That is the way *you* as repo people recommended it. If you have a problem with the jar being twice in your repo, well, maybe it is time that you get your act together and have an uniform policy for maven-1 and maven-2. If you do not agree here, then we will go to org.apache.texen and org.apache.anakia and drop the jars in the velocity group. I am not really interested in second guessing what you want to have and how you intend to organize it. The maven repos are a distribution mechanism, not a policy tool. Please rename the .bak directories. Feel free to drop the jars from the velocity group at your discretion, I do not really care. Best regards Henning Carlos Sanchez schrieb: I guess these are the same as the ones in http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars - they should be only in the m1 OR m2 repo - Putting them in two different groupIds is confusing - if they are subprojects of velocity they should be in org.apache.velocity.* - missing PGP signatures I've moved anakia and texen out of the way for the moment (to .bak) On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Repository changed == Repository: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/ Added - [henning] org/apache/anakia [henning] org/apache/anakia/anakia [henning] org/apache/anakia/anakia/1.0 [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5 [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.sha1 [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.md5 [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.sha1 [henning] org/apache/anakia/anakia/maven-metadata.xml [henning] org/apache/anakia/anakia/maven-metadata.xml.md5 [henning] org/apache/anakia/anakia/maven-metadata.xml.sha1 [henning] org/apache/texen [henning] org/apache/texen/texen [henning] org/apache/texen/texen/1.0 [henning] org/apache/texen/texen/1.0/texen-1.0.jar [henning] org/apache/texen/texen/1.0/texen-1.0.jar.md5 [henning] org/apache/texen/texen/1.0/texen-1.0.jar.sha1 [henning] org/apache/texen/texen/1.0/texen-1.0.pom [henning] org/apache/texen/texen/1.0/texen-1.0.pom.md5 [henning] org/apache/texen/texen/1.0/texen-1.0.pom.sha1 [henning] org/apache/texen/texen/maven-metadata.xml [henning] org/apache/texen/texen/maven-metadata.xml.md5 [henning] org/apache/texen/texen/maven-metadata.xml.sha1 Removed --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COMMITTERS] rebuilding the various sites
Hi, Will Glass-Husain schrieb: Hi Henning, I'm trying to rebuild the engine docs. There's a few minor things missing from your notes which I note below. (perhaps they are all obvious). But I'm still stuck. (1) You need to set JAVA_HOME JAVA_HOME=/usr/jdk/latest/ export JAVA_HOME Yes /usr/java or /usr/j2sdk (2) You need to have mvn in your path /local/bin/mvn Yes. /usr/local/bin is even better. (3) After calling the script to build the site, you need to go to the site directory before running maven. cd /export/home/velocity/deploy/velocity-engine-site/ No. Normally, the script should build and deploy in one go. No more steps needed. HOWEVER, I'm getting an error when I run the following. Any suggestions? Yes. This is intentional. It means that you are not using the local repo in ~velocity/.m2/repository. The -beta-6 is the version with patches build locally. There is not beta-6 on the global repos. Can you tell me exactly what commands you ran? Normally a newgrp velocity ~velocity/bin/
[ANNOUNCE] Apache Velocity DocBook Framework 1.0 released
The Velocity developers are very pleased to announce the first release of the Velocity DocBook Framework (DBF). It is intended to help creating high-quality documentation in the Docbook format which can be used online or as PDF for print out. Downloads and documentation are available from http://velocity.apache.org/docbook/ -- The Apache Velocity team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] Release Velocity DocBook Framework 1.0
[ Apologies for the delay in announcing the results. ] The vote is closed. +1: Henning Schmiedehausen (PMC Member) Will Glass-Husain (PMC Member) Nathan Bubna (PMC Member) 0: none -1: none I moved the release tarballs into the download area, added a tiny site for it to velocity.apache.org and will send out an announcement shortly. Best regards Henning On Wed, 2007-03-21 at 23:07 +0100, Henning Schmiedehausen wrote: > [Let's say, it will not get better and I'm already bored out of my mind > again tinkering with XSL and XML.] > > This is the CfV for the first release of the Velocity DocBook Framework. > It is intended for creating and maintaining high quality documentation > generated in the DocBook format. The framework itself is completely > generic, non-intrusive, 100% bio-degradable and environment-friendly. > > The release candidate is available from > > http://people.apache.org/~henning/DocBook-Framework/ > > The documentation (which also serves as showcase example is visible at > http://people.apache.org/~henning/DocBook-Framework/DocBook-Framework-1.0.pdf) > > > [ ] +1 Let's do it > [ ] 0 I don't care. > [ ] -1 No, because __ > > > Voting period is until Sunday, March 25th, 2007, 12:00 CEST (> 72h). > > My vote is +1 > > Best regards > Henning > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-536) Velocity Engine throws NullPointer Exception when two people click on the same page at the same time for the first time
[ https://issues.apache.org/jira/browse/VELOCITY-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487506 ] Henning Schmiedehausen commented on VELOCITY-536: - Hm, I'm late to that show. :-( I did not read up all the thread, but please consider http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html which is the bible on why DCL is broken. Even though there is mentioned that it works for 32 bit integers, the summary is "this is not worth the trouble". I'm completely with Christopher here. DCL code should be actively removed from a code base, not added. Even if it is the corner case for "32 bit primitives". > Velocity Engine throws NullPointer Exception when two people click on the > same page at the same time for the first time > --- > > Key: VELOCITY-536 > URL: https://issues.apache.org/jira/browse/VELOCITY-536 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Lei Gu > Attachments: 536-patch.txt, ASTDirective.java, ASTSetDirective.java, > VelocimacroProxy.java > > > Multi-thread concurrency issue > During our concurrency testing, we observed NullPointer exceptions being > thrown when two people hit the same page at the same time for the first time. > Upon further investigation, it turns out that we need to synchronize the init > method on ASTDirective, ASTSetDirective, and render method on > ASTSetDirective, and VelocimacroProxy. > Basically, the problem is introduced as the following; when two threads > attempts to parse and render the same template at the same time. Thread1 > finishes parsing first and proceeds to the render method call, while thread 2 > is still busy parsing and will overwrite the existing parse tree that is > being used by thread 1 for rendering purpose. Thus under certainly condition > a NullPointer exception will be thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Incubation of the Click Project at the Apache Software Foundation]
Thank you, Ted! Happy Easter! Henning On Sat, 2007-04-07 at 17:00 -0400, Ted Husted wrote: > I'd like to volunteer as a Mentor for for Click. > > -Ted. > > On 4/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: > > Hi, > > > > thanks. According to the current discussion on [EMAIL PROTECTED], it > > seems that actually all mentors must be members. As Daniel and Geir are > > currently probably pretty busy, we will have to recruit someone from > > outside Velocity to help. > > > > Best regards > > Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Incubation of the Click Project at the Apache Software Foundation]
Hi, thanks. According to the current discussion on [EMAIL PROTECTED], it seems that actually all mentors must be members. As Daniel and Geir are currently probably pretty busy, we will have to recruit someone from outside Velocity to help. Best regards Henning On Tue, 2007-04-03 at 15:57 -0700, Will Glass-Husain wrote: > I volunteer. (and as you know, I'm an ASF member). > > Will > > On 4/3/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > that is really good news. Congratulations to the Click Community to be > > willing to take this step! > > > > Our next step will be now to start drafting up a proposal. I'd suggest > > that we do so on the Velocity Wiki (unless Click has its own Wiki > > somewhere). > > > > As said before, I'd volunteer as Champion. We also need a number of > > mentors (as I just got drafted into a proposal on the Incubator, three > > seems to be a good number), of which one *must* be an ASF member. So we > > need some volunteers here. > > > > More later, I will have to read up on the exact rules myself. :-) > > > > Best regards > > Henning > > > > > > On Fri, 2007-03-30 at 22:12 +1000, Malcolm Edgar wrote: > > > Hi All, > > > > > > The Click move to Apache vote is in. We have a positive vote, with 1 > > > abstention and 4 positive votes. > > > > > > [ 0 ] Ahmed Mohombe > > > > > > [+1] Malcolm Edgar > > > > > > [+1] Bob Schellink > > > > > > [+1] Stephen Haberman > > > > > > [+1] Naoki Takezoe > > > > > > So I would like to move forward to the Apache incubation process for > > Click. > > > > > > As I imagine the incubation process will take some time, I propose to > > > have a sourceforge Click 1.3 release, before an Apache Click release. > > > > > > If the Apache migration is accepted, I don't think we should fork the > > > code base maintaining parallel sourceforge and apache branches, as the > > > overhead would be prohibitive. > > > > > > regards Malcolm Edgar > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://velocity.apache.org/download.cgi - Internal Server Error
Yep. Brain-too-tired-error. :-) Actually, the best way would have been: cp download.cgi /tmp rm download.cgi mv /tmp/download.cgi . chmod 755 download.cgi One of the perks of Unix is, that you can unlink the file (write permission to the directory) but not change its permissions. Sorry for the noise. Best regards Henning Joe Schaefer schrieb: "Will Glass-Husain" <[EMAIL PROTECTED]> writes: Is there some type of ACL on this that won't allow me (member of group but not file owner) to set to executable? No, that's just how chmod works: $ man chmod ... Only the owner of a file or the super-user is permitted to change the mode of a file. WILL On 4/4/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: On Wed, 2007-04-04 at 09:07 -0700, Will Glass-Husain wrote: I fixed this, because I owned the file. Normally this should have worked; at least after a "newgrp velocity". Which does not work (Operation not permitted). Infra? > Hmm... couldn't fix this. What am I missing? > > [EMAIL PROTECTED] /x1/www/velocity.apache.org]$ ls -l download.cgi > -rw-rw-r-- 1 henning velocity 883 Mar 31 19:37 download.cgi > > [EMAIL PROTECTED] /x1/www/velocity.apache.org]$ groups > wglass apcvs jakarta member apsite velocity > > [EMAIL PROTECTED] /x1/www/velocity.apache.org]$ chmod a+x download.cgi > chmod: download.cgi: Operation not permitted Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity DocBook Framework 1.0
Yes. I was over my ears this week, tonight will be official announcement, I reserved some time for doing it. Best regards Henning Ted Husted schrieb: So, did this get released? I I've been working in DocBook myself lately. -Ted. On 3/21/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: [Let's say, it will not get better and I'm already bored out of my mind again tinkering with XSL and XML.] This is the CfV for the first release of the Velocity DocBook Framework. It is intended for creating and maintaining high quality documentation generated in the DocBook format. The framework itself is completely generic, non-intrusive, 100% bio-degradable and environment-friendly. The release candidate is available from http://people.apache.org/~henning/DocBook-Framework/ The documentation (which also serves as showcase example is visible at http://people.apache.org/~henning/DocBook-Framework/DocBook-Framework-1.0.pdf) [ ] +1 Let's do it [ ] 0 I don't care. [ ] -1 No, because __ Voting period is until Sunday, March 25th, 2007, 12:00 CEST (> 72h). My vote is +1 Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://velocity.apache.org/download.cgi - Internal Server Error
On Wed, 2007-04-04 at 09:07 -0700, Will Glass-Husain wrote: I fixed this, because I owned the file. Normally this should have worked; at least after a "newgrp velocity". Which does not work (Operation not permitted). Infra? > Hmm... couldn't fix this. What am I missing? > > [EMAIL PROTECTED] /x1/www/velocity.apache.org]$ ls -l download.cgi > -rw-rw-r-- 1 henning velocity 883 Mar 31 19:37 download.cgi > > [EMAIL PROTECTED] /x1/www/velocity.apache.org]$ groups > wglass apcvs jakarta member apsite velocity > > [EMAIL PROTECTED] /x1/www/velocity.apache.org]$ chmod a+x download.cgi > chmod: download.cgi: Operation not permitted Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Incubation of the Click Project at the Apache Software Foundation]
Hi, that is really good news. Congratulations to the Click Community to be willing to take this step! Our next step will be now to start drafting up a proposal. I'd suggest that we do so on the Velocity Wiki (unless Click has its own Wiki somewhere). As said before, I'd volunteer as Champion. We also need a number of mentors (as I just got drafted into a proposal on the Incubator, three seems to be a good number), of which one *must* be an ASF member. So we need some volunteers here. More later, I will have to read up on the exact rules myself. :-) Best regards Henning On Fri, 2007-03-30 at 22:12 +1000, Malcolm Edgar wrote: > Hi All, > > The Click move to Apache vote is in. We have a positive vote, with 1 > abstention and 4 positive votes. > > [ 0 ] Ahmed Mohombe > > [+1] Malcolm Edgar > > [+1] Bob Schellink > > [+1] Stephen Haberman > > [+1] Naoki Takezoe > > So I would like to move forward to the Apache incubation process for Click. > > As I imagine the incubation process will take some time, I propose to > have a sourceforge Click 1.3 release, before an Apache Click release. > > If the Apache migration is accepted, I don't think we should fork the > code base maintaining parallel sourceforge and apache branches, as the > overhead would be prohibitive. > > regards Malcolm Edgar > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Incubation of the Click Project at the Apache Software Foundation]
I sent this message out to the Click people this weekend to encourage them to discuss possible incubation at the ASF. I offered to be Champion and I'd say that Velocity will be the sponsoring PMC. There is notion that Click will go to top-level but it might as well end up as part of Velocity. This is basically a FYI, until the Click community decided where to go, there is not much to do for us (I think) to encourage them and be helpful if questions arise. Best regards Henning Forwarded Message > From: Henning Schmiedehausen <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: Malcolm Edgar <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Incubation of the Click Project at the Apache Software > Foundation > Date: Sat, 24 Mar 2007 17:36:51 +0100 > > Hi, > > this message goes out to the Apache Velocity PMC and the Click > Development list. For those of you who do not know anything about me > (probably most Click developers not directly involved with Velocity), I > am the current chair of the project management committee (PMC) of the > Apache Velocity project. > > End of last year, we discussed with Malcolm Edgar about opportunities to > bring Click to the Apache Software Foundation in general and > specifically to the Velocity project. > > I would like to review this now and if we agree that this is a good > thing, prepare to start the incubation process. > > Personally, I'm very much in favor of doing this. > > What must be understood however, before we kick off the process to bring > Click in, is that the ASF is interested in communities more than code. > > Which means, that the most important thing for us is to get acceptance > and embrace from the people who currently *are* the Click community. The > ASF is not a big vacuum cleaner that sucks in code and slaps an ASF logo > and the feather brand on top of it. > > What we (the "Apache people") request from "you" (the "Click people") > now, is that you form consensus. I reviewed your mailing lists and there > was mixed discussion about this move and I found no consensus. So this > would be needed first before any of the incubation process could start. > > I did read some points about bureaucracy. The following list is a > personal compilation and should not be seen as canonical: > > * Yes, the ASF has some of that. We are not just an open source >project. There is some legalese involved and we do offer a >legal protection umbrella for our projects. This also means, that >there are some rules for dependencies and releases that we are >quite adamant about. > > * No, the foundation does not play into your project. If you run > your project fast and loose, we let you do so most of the time. > > * No, as a developer / committer, the bureaucracy does not touch > you most of the times. It is the job of the people serving on the > entities of the foundation (like the PMC) to provide oversight and > guidance to any project. Joining a PMC is a voluntary act and while > most developers choose to do so at some point, there are some that > say no. > > * Yes, as a developer, there are harder rules to e.g. dependencies > inside the ASF than outside. You do have to play by the rules, there > are no exceptions. The rules sometimes change, though. As a part > of the foundation you *can* influence these changes. > > * Yes, as a developer / committer, you *must* sign a formal CLA before > you can work on a project. Even if you already have commit rights to > the project. This is a formal requirement and part of the incubation > process and also an one-step thing (you fill out a form, fax it in). > > * Yes and no, incubation can be a drag. It is a formal process and it > works as well as the people involved. If a project drags incubation, > this is not the fault of the foundation. We had projects whiz through > it in a few (1-3) months, we have projects in there for years. > If Click joins the ASF, I intend to do the former, not the latter. > Please understand, that every incubation is different. Experiences > from another project are no indication for the next project. YMMV. > > For those of you interested in the incubation process, there is a > summary on > http://incubator.apache.org/incubation/Incubation_Policy.html > > There is a lot of boring stuff in there, but then again, this is more a > formal process than anything else and this process is normally done by > the mentors and a few selected members of the project development > community. It does not touch or influence any users and developers that > do not want to
Re: Incubation of the Click Project at the Apache Software Foundation
No bad intent here. I just thought that it would be premature to start discussing this in our developer community; it might very well be possible that the Click community decides that Apache is not for them. I Cc'ed [EMAIL PROTECTED] and I will resend my mail to the dev list. Best regards Henning On Mon, 2007-03-26 at 07:17 -0400, Geir Magnusson Jr. wrote: > Why aren't we discussing this on the Velocity dev list? It's not > like this is really private, since we're cc-ing the click-dev list... > > geir > > On Mar 26, 2007, at 7:13 AM, Malcolm Edgar wrote: > > > Hi All, > > I would like to continue this discussion on Clicks future and the > > proposal to make a Click an Apache project. First up I would like to > > thank Henning for offering to be Click's "Incubation champion". > > > > Over the last few months we have had some on and off discussions about > > Click becoming an Apache project. While the general consensus has > > been positive, a number of developers and users have voiced their > > reservations for this move. > > The reason I am keen to make Click an Apache project is to see the > > framework obtain the recognition that it deserves, and to see a larger > > development community move the project forward. > > > > I have contributed a great deal of time to get Click to the position > > it is today. I also acknowledge and am very grateful for the > > contributions and guidance from the Click development community. > > Going forward I will not be able maintain this same level of effort, > > so building a broader development community is important for > > sustaining Clicks future. > > > > I would like to see Click become a top level Apache project > > (click.apache.org) at the same level as the other Apache web > > application frameworks such as Struts and Tapestry. This would > > maximize Clicks visibility and viability to Architects evaluating > > whether to use Click in web application projects. > > > > The way I would like this proposal to be evaluated is through an > > Apache style vote, where by a negative vote -1 will veto the proposal, > > a +0 vote has no opinion and a +1 vote is supporting. While general > > community votes are welcome, click-developer votes will be binding. > > > > [ ]Ahmed Mohombe > > > > [ ]Christian Essl > > > > [+1] Malcolm Edgar > > > > [ ]Phil Barnes > > > > [ ]Bob Schellink > > > > [ ]Stephen Haberman > > > > [ ]Naoki Takezoe > > > > If you make a -1 binding vote, please raise your issues so that they > > can be discussed to see whether they can be addressed and a consensus > > can be achieved. > > > > This approach is different from the benevolent dictatorship I have > > been running so far. > > > > Regards Malcolm Edgar > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-531) Some user feedback / wishes from the O'Reilly blog
Some user feedback / wishes from the O'Reilly blog -- Key: VELOCITY-531 URL: https://issues.apache.org/jira/browse/VELOCITY-531 Project: Velocity Issue Type: Wish Affects Versions: 1.5 Reporter: Henning Schmiedehausen Fix For: 1.6 Look into the wishlist at http://www.oreillynet.com/onjava/blog/2007/03/velocity_15.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Velocity DocBook Framework 1.0
[Let's say, it will not get better and I'm already bored out of my mind again tinkering with XSL and XML.] This is the CfV for the first release of the Velocity DocBook Framework. It is intended for creating and maintaining high quality documentation generated in the DocBook format. The framework itself is completely generic, non-intrusive, 100% bio-degradable and environment-friendly. The release candidate is available from http://people.apache.org/~henning/DocBook-Framework/ The documentation (which also serves as showcase example is visible at http://people.apache.org/~henning/DocBook-Framework/DocBook-Framework-1.0.pdf) [ ] +1 Let's do it [ ] 0 I don't care. [ ] -1 No, because __ Voting period is until Sunday, March 25th, 2007, 12:00 CEST (> 72h). My vote is +1 Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site Building Tools
Hi, after discussion with Jason, I decided to put work on the various tools for site building on hold until after the 2.0.6 maven release which should happen in the next few days. If there is any immediate need to rebuild the Velocity sites, please ping me. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [repo] /www/people.apache.org/repo/m1-ibiblio-rsync-repository/]
Forwarded Message
> From: Carlos Sanchez <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: repository@apache.org
> Subject: Re:
> [repo] /www/people.apache.org/repo/m1-ibiblio-rsync-repository/
> Date: Wed, 14 Mar 2007 10:44:06 -0700
>
> Hi,
>
> I've seen some things in the velocity pom that'd need to be improved
> so I moved it out of the way for now. Mostly the use of "provided"
> scope is wrong, probably meaning "optional"
>
> Please see attached diff or
> http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/poms/velocity-1.5.pom.carlos
> and let me know if it sounds right
>
>
> On 14 Mar 2007 09:15:00 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Repository changed
> > ==
> >
> > Repository: /www/people.apache.org/repo/m1-ibiblio-rsync-repository/
> >
> > Added
> > -
> > [henning] velocity/jars/velocity-1.5.jar
> > [henning] velocity/jars/velocity-1.5.jar.md5
> > [henning] velocity/jars/velocity-1.5.jar.asc
> > [henning] velocity/poms/velocity-1.5.pom.md5
> > [henning] velocity/poms/velocity-1.5.pom
> >
> > Removed
> > ---
> >
>
>
--
Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux,
|gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [repo] /www/people.apache.org/repo/m1-ibiblio-rsync-repository/
Hi Carlos, AFAIK, maven-1 does not use the POMs stored in the repo anyway. At least I do not plan to support the maven-1 repos beyond this release anyway. We pushed the POM into the maven-2 repo and it seems to work well there. Thanks for the patch (I will forward it to our dev list), I will look into the POM becoming a "better Apache Repo citizen" for the next release anyway. Best regards Henning On Wed, 2007-03-14 at 10:44 -0700, Carlos Sanchez wrote: > Hi, > > I've seen some things in the velocity pom that'd need to be improved > so I moved it out of the way for now. Mostly the use of "provided" > scope is wrong, probably meaning "optional" > > Please see attached diff or > http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/poms/velocity-1.5.pom.carlos > and let me know if it sounds right > > > On 14 Mar 2007 09:15:00 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Repository changed > > == > > > > Repository: /www/people.apache.org/repo/m1-ibiblio-rsync-repository/ > > > > Added > > - > > [henning] velocity/jars/velocity-1.5.jar > > [henning] velocity/jars/velocity-1.5.jar.md5 > > [henning] velocity/jars/velocity-1.5.jar.asc > > [henning] velocity/poms/velocity-1.5.pom.md5 > > [henning] velocity/poms/velocity-1.5.pom > > > > Removed > > --- > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On Wed, 2007-03-07 at 15:35 -0800, Nathan Bubna wrote: > > > > Now that we have the engine release, I will put the jar into the maven > > repos > > how is this done? As we don't build with maven-2, we can not deploy automatically. I pulled the release jar down from www.apache.org/dist into /tmp/velocity-1.5.jar and ran mvn -Dfile=/tmp/velocity-1.5.jar -DrepositoryId=apache.releases -DpomFile=pom.xml -Durl=scpexe://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository -Dpackaging=jar deploy:deploy-file (before I had to add apache.releases henning to my settings.xml) That put the POM and the jar into the repo on people. I compared the checksums in the repo and the distribution directory and they are the same. This should be enough to get 1.5 out. For the next release (1.5.1 or 1.6) I want to tweak it a bit. See http://issues.apache.org/jira/browse/VELOCITY-526 Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-434) Commons pool implementation of the parser pool
[
https://issues.apache.org/jira/browse/VELOCITY-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-434.
---
> Commons pool implementation of the parser pool
> --
>
> Key: VELOCITY-434
> URL: https://issues.apache.org/jira/browse/VELOCITY-434
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Reporter: Serge Knystautas
>Priority: Minor
> Attachments: CommonsParserPool.java, CommonsParserPool.java,
> CommonsParserPoolFactory.java
>
>
> Now that with [Velocity-433] we can swap out the parser pool, here is a
> parser pool that uses commons-pool (http://jakarta.apache.org/commons/pool/).
> It is very primitive configuration and uses the same configuration name
> (parser.pool.size) for maximum number of elements in the pool. It is also
> configured to grow when the maximum number is exhausted, which means that it
> scales the same way as the original parser, while actually providing some
> better pool support.
> One of the nicest parts about this is that you can set your maximum instances
> to 0 and still get great performance. The first time you need a parser, it
> will still add one even though the max is reached (since grow when exhausted
> is set). Assuming the second time you need a parser is within a few seconds,
> that first instance is still there.
> Here is some sample code of how to use it your app.
> Properties configuration = new Properties();
> configuration.put("parser.pool.class",
> "com.lokitech.util.pool.CommonsParserPool");
> configuration.put("parser.pool.size", "0");
> Velocity.init(configuration);
> Since Velocity does not have an existing dependency on commons pool, I'm not
> sure this code will get packaged into the main distribution. This code is
> licensed using ASL 2.0, so please reuse however you want as long as
> attribution is kept per the license.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-353) [patch] LRUMap missing from velocity-dep
[ https://issues.apache.org/jira/browse/VELOCITY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-353. --- > [patch] LRUMap missing from velocity-dep > > > Key: VELOCITY-353 > URL: https://issues.apache.org/jira/browse/VELOCITY-353 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 1.5 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Brett Porter > Attachments: patch.txt > > > Hi, > LRUMap from commons-collections was added to Velocity here: > http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/src/java/org/apache/velocity/runtime/resource/ResourceCacheImpl.java?r1=1.2&r2=1.3&diff_format=h > However, it is not included in velocity-dep. > Attached is a patch to build/build.xml to correct this. It is currently > causing > a failure in Gump for the Apache Directory Server. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-344) Some files have wrong line endings in the SVN repository.
[ https://issues.apache.org/jira/browse/VELOCITY-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-344. --- > Some files have wrong line endings in the SVN repository. > - > > Key: VELOCITY-344 > URL: https://issues.apache.org/jira/browse/VELOCITY-344 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 1.5 > Environment: Operating System: All > Platform: PC >Reporter: Shinobu Kawai > Assigned To: Velocity-Dev List >Priority: Blocker > > Some files have wrong file endings in the SVN repository. > See here for details: > http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=velocity- > [EMAIL PROTECTED]&msgNo=11309 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-243) No call to test case IntrospectorTestCase3.java
[
https://issues.apache.org/jira/browse/VELOCITY-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-243.
---
> No call to test case IntrospectorTestCase3.java
> ---
>
> Key: VELOCITY-243
> URL: https://issues.apache.org/jira/browse/VELOCITY-243
> Project: Velocity
> Issue Type: Bug
> Components: Testing
>Affects Versions: 1.5
> Environment: Operating System: other
> Platform: Other
>Reporter: Will Glass-Husain
> Assigned To: Velocity-Dev List
>Priority: Minor
>
> Happened to notice that the test case "IntrospectorTestCase3.java" is never
> checked with ant test.
> Inserting this should solve it. (also adding test-introspect3 to the test
> target). And yes, the test works with CVS head.
>
>
> failonerror="${testbed.failonerror}">
>
>
>
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-343) Link to nightly snapshots.
[ https://issues.apache.org/jira/browse/VELOCITY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-343. --- > Link to nightly snapshots. > -- > > Key: VELOCITY-343 > URL: https://issues.apache.org/jira/browse/VELOCITY-343 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 1.5 > Environment: Operating System: All > Platform: PC >Reporter: Shinobu Kawai > Assigned To: Velocity-Dev List >Priority: Minor > Attachments: dvsl.nightly.snapshot.patch, nightly.snapshots.patch > > > Restart nightly snapshots. > See here for details: > http://mail-archives.apache.org/eyebrowse/BrowseList?listName=velocity- > [EMAIL PROTECTED]&by=thread&from=945779 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-344) Some files have wrong line endings in the SVN repository.
[ https://issues.apache.org/jira/browse/VELOCITY-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-344. --- > Some files have wrong line endings in the SVN repository. > - > > Key: VELOCITY-344 > URL: https://issues.apache.org/jira/browse/VELOCITY-344 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 1.5 > Environment: Operating System: All > Platform: PC >Reporter: Shinobu Kawai > Assigned To: Velocity-Dev List >Priority: Blocker > > Some files have wrong file endings in the SVN repository. > See here for details: > http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=velocity- > [EMAIL PROTECTED]&msgNo=11309 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-171) Add target to build.xml to create doc tarball
[
https://issues.apache.org/jira/browse/VELOCITY-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-171.
---
> Add target to build.xml to create doc tarball
> -
>
> Key: VELOCITY-171
> URL: https://issues.apache.org/jira/browse/VELOCITY-171
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.3.1-rc2
> Environment: Operating System: other
> Platform: Other
>Reporter: Tim Colson
> Assigned To: Velocity-Dev List
>Priority: Minor
>
> Tiny little patch for build.xml to add in a 'tardocs' target which builds a
> compressed tarball for the docs/xdocs trees. This is just an interim
> convenience so that the docs can be easily published to a web server until
> the
> jakarta publishing process is figured out.
> Timo
> Index: build.xml
> ===
> RCS file: /home/cvspublic/jakarta-velocity-tools/build.xml,v
> retrieving revision 1.13
> diff -u -r1.13 build.xml
> --- build.xml 26 Apr 2003 01:31:01 - 1.13
> +++ build.xml 26 Apr 2003 15:55:55 -
> @@ -280,5 +280,17 @@
>
> +
> +
> +
> + +description="Combine all xdocs and docs into a tar ball.">
> +
> + +basedir="${basedir}"
> +includes="docs/**,xdocs/**"
> +compression="gzip"
> +/>
> +
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-343) Link to nightly snapshots.
[ https://issues.apache.org/jira/browse/VELOCITY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-343. --- > Link to nightly snapshots. > -- > > Key: VELOCITY-343 > URL: https://issues.apache.org/jira/browse/VELOCITY-343 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 1.5 > Environment: Operating System: All > Platform: PC >Reporter: Shinobu Kawai > Assigned To: Velocity-Dev List >Priority: Minor > Attachments: dvsl.nightly.snapshot.patch, nightly.snapshots.patch > > > Restart nightly snapshots. > See here for details: > http://mail-archives.apache.org/eyebrowse/BrowseList?listName=velocity- > [EMAIL PROTECTED]&by=thread&from=945779 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-243) No call to test case IntrospectorTestCase3.java
[
https://issues.apache.org/jira/browse/VELOCITY-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-243.
---
> No call to test case IntrospectorTestCase3.java
> ---
>
> Key: VELOCITY-243
> URL: https://issues.apache.org/jira/browse/VELOCITY-243
> Project: Velocity
> Issue Type: Bug
> Components: Testing
>Affects Versions: 1.5
> Environment: Operating System: other
> Platform: Other
>Reporter: Will Glass-Husain
> Assigned To: Velocity-Dev List
>Priority: Minor
>
> Happened to notice that the test case "IntrospectorTestCase3.java" is never
> checked with ant test.
> Inserting this should solve it. (also adding test-introspect3 to the test
> target). And yes, the test works with CVS head.
>
>
> failonerror="${testbed.failonerror}">
>
>
>
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-171) Add target to build.xml to create doc tarball
[
https://issues.apache.org/jira/browse/VELOCITY-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-171.
---
> Add target to build.xml to create doc tarball
> -
>
> Key: VELOCITY-171
> URL: https://issues.apache.org/jira/browse/VELOCITY-171
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.3.1-rc2
> Environment: Operating System: other
> Platform: Other
>Reporter: Tim Colson
> Assigned To: Velocity-Dev List
>Priority: Minor
>
> Tiny little patch for build.xml to add in a 'tardocs' target which builds a
> compressed tarball for the docs/xdocs trees. This is just an interim
> convenience so that the docs can be easily published to a web server until
> the
> jakarta publishing process is figured out.
> Timo
> Index: build.xml
> ===
> RCS file: /home/cvspublic/jakarta-velocity-tools/build.xml,v
> retrieving revision 1.13
> diff -u -r1.13 build.xml
> --- build.xml 26 Apr 2003 01:31:01 - 1.13
> +++ build.xml 26 Apr 2003 15:55:55 -
> @@ -280,5 +280,17 @@
>
> +
> +
> +
> + +description="Combine all xdocs and docs into a tar ball.">
> +
> + +basedir="${basedir}"
> +includes="docs/**,xdocs/**"
> +compression="gzip"
> +/>
> +
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-119) Velocity resource problems using Jboss-3.0.4_Tomcat-4.0.6 bundle
[
https://issues.apache.org/jira/browse/VELOCITY-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-119.
---
> Velocity resource problems using Jboss-3.0.4_Tomcat-4.0.6 bundle
>
>
> Key: VELOCITY-119
> URL: https://issues.apache.org/jira/browse/VELOCITY-119
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: PC
>Reporter: Fred Moulden
> Assigned To: Velocity-Dev List
>
> I am using the velocity-tools (0.6) and Struts (1.02) to build an application
> that will run in JBoss. I subclassed VelocityViewServlet to perform some
> specific startup functions. JBoss does not unpack WARs and some references
> were returning java.io.FileNotFound errors.
> I tracked the problem to VelocityServlet.loadConfiguration(ServletConfig
> config). The following worked for me:
> I changed this code fragment from this
> Properties p = new Properties();
>
> if ( propsFile != null )
> {
> String realPath = getServletContext().getRealPath(propsFile);
>
> if ( realPath != null )
> {
> propsFile = realPath;
> }
> p.load( new FileInputStream(propsFile) );
> }
> return p;
> to this
> Properties p = new Properties();
>
> if ( propsFile != null )
> {
> InputStream is = getClass().getClassLoader().getResourceAsStream
> ( propsFile );
> p.load( is );
> }
> return p;
> No other external settings/configurations worked until this change was made.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-23) Add handling of primitive arrays with foreach
[
https://issues.apache.org/jira/browse/VELOCITY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-23.
--
> Add handling of primitive arrays with foreach
> -
>
> Key: VELOCITY-23
> URL: https://issues.apache.org/jira/browse/VELOCITY-23
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.1
> Environment: Operating System: other
> Platform: Other
>Reporter: Dale King
> Assigned To: Velocity-Dev List
>
> It would be really nice if you added support for primitive arrays with
> foreach.
> You currently handle arrays of objects by creating an iterator for the array
> when invoking foreach on it. Why not do the same thing with primitive arrays.
> I know you will probably tell me that I can always create my own wrapper
> around
> the array, but that has its problems.
> I can create my own Iterator wrapper and add it to the context, but what if I
> need to use that data in multiple foreach statements? I can't use the same
> iterator more than once.
> I could create a Collection wrapper for the array, but that is a lot of extra
> work. I don't need the entire collection interface I just want you to iterate
> over the array.
> I could create another array creating wrappers for each item (e.g. if I have
> a
> byte[] create a Byte[]), but that is horribly inefficient for arrays of any
> size.
> So the best solution is for Velocity to create an iterator on demand.
> It really is not difficult to actually achieve. You already have the
> ArrayIterator class for iterating over arrays of Object. It is easily
> modified
> to work with any array. Or you can create a separate iterator for primitive
> arrays.
> To see how to do that here is the source for the PrimitiveArrayIterator from
> WebMacro which you can compare to your ArrayIterator:
> final public class PrimitiveArrayIterator implements Iterator
> {
>private final Object a;
>private int _size;
>private int pos;
>public PrimitiveArrayIterator(Object array)
>{
> if (!array.getClass().isArray())
> throw new IllegalArgumentException(array.getClass().getName()
> + " is not an array.");
> this.a = array;
> _size = java.lang.reflect.Array.getLength(a);
> pos = 0;
>}
>/**
> * Return true if we have not yet reached the end of the enumeration
> */
>final public boolean hasNext()
>{
> return (pos < _size);
>}
>/**
> * Advance the iterator and return the next value. Return null if we
> * reach the end of the enumeration.
> */
>final public Object next() throws NoSuchElementException
>{
> if (pos < _size) {
> return java.lang.reflect.Array.get(a, pos++);
> } else {
> throw new NoSuchElementException("Advanced beyond end of array");
> }
>}
>final public void remove() throws UnsupportedOperationException
>{
> throw new UnsupportedOperationException();
>}
> }
> If you changed your ArrayIterator to work with any type of array then all you
> have to change is instead of this in ForEach.java:
> if( listObject instanceof Object[] )
> You would have:
> if( listObject.getClass().isArray() )
> And you would not have the cast when creating the ArrayIterator further down.
> By the way, while looking at this I noticed that Context.java has an unused
> import of ArrayIterator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-119) Velocity resource problems using Jboss-3.0.4_Tomcat-4.0.6 bundle
[
https://issues.apache.org/jira/browse/VELOCITY-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-119.
---
> Velocity resource problems using Jboss-3.0.4_Tomcat-4.0.6 bundle
>
>
> Key: VELOCITY-119
> URL: https://issues.apache.org/jira/browse/VELOCITY-119
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: PC
>Reporter: Fred Moulden
> Assigned To: Velocity-Dev List
>
> I am using the velocity-tools (0.6) and Struts (1.02) to build an application
> that will run in JBoss. I subclassed VelocityViewServlet to perform some
> specific startup functions. JBoss does not unpack WARs and some references
> were returning java.io.FileNotFound errors.
> I tracked the problem to VelocityServlet.loadConfiguration(ServletConfig
> config). The following worked for me:
> I changed this code fragment from this
> Properties p = new Properties();
>
> if ( propsFile != null )
> {
> String realPath = getServletContext().getRealPath(propsFile);
>
> if ( realPath != null )
> {
> propsFile = realPath;
> }
> p.load( new FileInputStream(propsFile) );
> }
> return p;
> to this
> Properties p = new Properties();
>
> if ( propsFile != null )
> {
> InputStream is = getClass().getClassLoader().getResourceAsStream
> ( propsFile );
> p.load( is );
> }
> return p;
> No other external settings/configurations worked until this change was made.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-23) Add handling of primitive arrays with foreach
[
https://issues.apache.org/jira/browse/VELOCITY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-23.
--
> Add handling of primitive arrays with foreach
> -
>
> Key: VELOCITY-23
> URL: https://issues.apache.org/jira/browse/VELOCITY-23
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.1
> Environment: Operating System: other
> Platform: Other
>Reporter: Dale King
> Assigned To: Velocity-Dev List
>
> It would be really nice if you added support for primitive arrays with
> foreach.
> You currently handle arrays of objects by creating an iterator for the array
> when invoking foreach on it. Why not do the same thing with primitive arrays.
> I know you will probably tell me that I can always create my own wrapper
> around
> the array, but that has its problems.
> I can create my own Iterator wrapper and add it to the context, but what if I
> need to use that data in multiple foreach statements? I can't use the same
> iterator more than once.
> I could create a Collection wrapper for the array, but that is a lot of extra
> work. I don't need the entire collection interface I just want you to iterate
> over the array.
> I could create another array creating wrappers for each item (e.g. if I have
> a
> byte[] create a Byte[]), but that is horribly inefficient for arrays of any
> size.
> So the best solution is for Velocity to create an iterator on demand.
> It really is not difficult to actually achieve. You already have the
> ArrayIterator class for iterating over arrays of Object. It is easily
> modified
> to work with any array. Or you can create a separate iterator for primitive
> arrays.
> To see how to do that here is the source for the PrimitiveArrayIterator from
> WebMacro which you can compare to your ArrayIterator:
> final public class PrimitiveArrayIterator implements Iterator
> {
>private final Object a;
>private int _size;
>private int pos;
>public PrimitiveArrayIterator(Object array)
>{
> if (!array.getClass().isArray())
> throw new IllegalArgumentException(array.getClass().getName()
> + " is not an array.");
> this.a = array;
> _size = java.lang.reflect.Array.getLength(a);
> pos = 0;
>}
>/**
> * Return true if we have not yet reached the end of the enumeration
> */
>final public boolean hasNext()
>{
> return (pos < _size);
>}
>/**
> * Advance the iterator and return the next value. Return null if we
> * reach the end of the enumeration.
> */
>final public Object next() throws NoSuchElementException
>{
> if (pos < _size) {
> return java.lang.reflect.Array.get(a, pos++);
> } else {
> throw new NoSuchElementException("Advanced beyond end of array");
> }
>}
>final public void remove() throws UnsupportedOperationException
>{
> throw new UnsupportedOperationException();
>}
> }
> If you changed your ArrayIterator to work with any type of array then all you
> have to change is instead of this in ForEach.java:
> if( listObject instanceof Object[] )
> You would have:
> if( listObject.getClass().isArray() )
> And you would not have the cast when creating the ArrayIterator further down.
> By the way, while looking at this I noticed that Context.java has an unused
> import of ArrayIterator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-83) #include directive a bad choice...
[ https://issues.apache.org/jira/browse/VELOCITY-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-83. -- > #include directive a bad choice... > -- > > Key: VELOCITY-83 > URL: https://issues.apache.org/jira/browse/VELOCITY-83 > Project: Velocity > Issue Type: Bug > Components: Testing >Affects Versions: 1.3-rc1 > Environment: Operating System: Solaris > Platform: Sun >Reporter: John > > I've come across a situation where I need to place netscape server-side > includes within my velocity template. > is seen to Velocity as a parse error since it's mistaking the netscape > include for a velocity include. > To me, this seems like a design flaw. Having netscape SSI calls in velocity > templates increases the flexibility of the templates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-150) Memory leak in resource loader
[
https://issues.apache.org/jira/browse/VELOCITY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-150.
---
> Memory leak in resource loader
> --
>
> Key: VELOCITY-150
> URL: https://issues.apache.org/jira/browse/VELOCITY-150
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.3
> Environment: Operating System: Linux
> Platform: Other
>Reporter: Kim Madsen
> Assigned To: Velocity-Dev List
> Fix For: 1.5
>
> Attachments: DataSource.patch, results.txt, results.xls,
> VelocityMemorySimple.java
>
>
> I am using Velocity in a J2EE application. I had problems with my application
> leaking memory. I have traced this back to Velocity. I have made a little
> simple
> JUnit test, which demonstrates this memory leak. It seems that every time you
> instantiate a Velocity Engine with a resource loader it leaks about 1.5 Kb of
> heap memory. If I do not include the setup of the resource loader from
> properties, there is no leak.
> I found this in Velocity 1.3, but I have tried the same test with a cvs
> checkout
> of Velocity from 4th of marts 2003, and it showed the same problem. If I let
> the
> test run with a max heap size of 64Mb, it will fail with OutOfMemoryError
> exception after about 34.000 iterations.
> I have attached the JUnit.
> Cheers, Kim Madsen
> Below follows my unit test
>
> package com.inceptor.rt;
> import com.inceptor.base.ExceptionBase;
> import com.inceptor.service.DiagnosticsFact;
> import com.inceptor.service.DiagnosticsIf;
> import com.inceptor.util.Test;
> import com.inceptor.util.TestSuite;
> import com.inceptor.util.TestCaseJUnit;
> import com.inceptor.util.Various;
> import java.io.StringWriter;
> import java.util.Properties;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.Template;
> import org.apache.velocity.app.VelocityEngine;
> /** Servlet used to test rt/Servlet functionality.
> *
> *
> * @version $Id: VelocityMemorySimple.java,v 1.3 2003/02/28 17:28:52 kim Exp $
> */
> public class VelocityMemorySimple
> extends TestCaseJUnit {
> private static final DiagnosticsIf diag =
> DiagnosticsFact.instance(VelocityMemorySimple.class);
> private static final int ROWS_BETWEEN_DISPLAY = 1000;
> private static final int ROWS_TO_ITERATE = 5 * ROWS_BETWEEN_DISPLAY;
>
> private static long lastTime = -1;
> public VelocityMemorySimple(String name) throws ExceptionBase {
> super(name);
> }
> ///
> private void showInfo(long rowsInserted)
> throws Exception {
> if (rowsInserted==0) {
> System.gc();
> lastTime = System.currentTimeMillis();
> }
>
> if (rowsInserted%ROWS_BETWEEN_DISPLAY == 0) {
> long nowTime = System.currentTimeMillis();
> System.gc();
> diag.info("Ite=" + rowsInserted
> + " Mem free ="
> + java.lang.Runtime.getRuntime().freeMemory()
> + " Mem total="
> + java.lang.Runtime.getRuntime().totalMemory()
> + " Ite/sec.="
> + ((double) 1000*ROWS_BETWEEN_DISPLAY)/(nowTime-lastTime)
> );
> lastTime = nowTime;
> }
> }
> public void testMemory()
> throws Exception {
> try {
> Properties p = new Properties();
>
> p.setProperty("runtime.log.logsystem.class",
>
> "org.apache.velocity.runtime.log.SimpleLog4JLogSystem");
> p.setProperty("runtime.log.logsystem.log4j.category", "VELOCITY");
>
> p.setProperty("resource.manager.logwhenfound", "true");
> p.setProperty("velocimacro.library", "");
> p.setProperty("resource.loader",
> "datasourceglobal, datasourcecustom");
>
> p.setProperty("datasourceglobal.resource.description",
> "Load Templates From java:ExcediaDB Global
> Resources");
> p.setProperty("datasourceglobal.resource.loader.class",
>
[jira] Closed: (VELOCITY-150) Memory leak in resource loader
[
https://issues.apache.org/jira/browse/VELOCITY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-150.
---
> Memory leak in resource loader
> --
>
> Key: VELOCITY-150
> URL: https://issues.apache.org/jira/browse/VELOCITY-150
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.3
> Environment: Operating System: Linux
> Platform: Other
>Reporter: Kim Madsen
> Assigned To: Velocity-Dev List
> Fix For: 1.5
>
> Attachments: DataSource.patch, results.txt, results.xls,
> VelocityMemorySimple.java
>
>
> I am using Velocity in a J2EE application. I had problems with my application
> leaking memory. I have traced this back to Velocity. I have made a little
> simple
> JUnit test, which demonstrates this memory leak. It seems that every time you
> instantiate a Velocity Engine with a resource loader it leaks about 1.5 Kb of
> heap memory. If I do not include the setup of the resource loader from
> properties, there is no leak.
> I found this in Velocity 1.3, but I have tried the same test with a cvs
> checkout
> of Velocity from 4th of marts 2003, and it showed the same problem. If I let
> the
> test run with a max heap size of 64Mb, it will fail with OutOfMemoryError
> exception after about 34.000 iterations.
> I have attached the JUnit.
> Cheers, Kim Madsen
> Below follows my unit test
>
> package com.inceptor.rt;
> import com.inceptor.base.ExceptionBase;
> import com.inceptor.service.DiagnosticsFact;
> import com.inceptor.service.DiagnosticsIf;
> import com.inceptor.util.Test;
> import com.inceptor.util.TestSuite;
> import com.inceptor.util.TestCaseJUnit;
> import com.inceptor.util.Various;
> import java.io.StringWriter;
> import java.util.Properties;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.Template;
> import org.apache.velocity.app.VelocityEngine;
> /** Servlet used to test rt/Servlet functionality.
> *
> *
> * @version $Id: VelocityMemorySimple.java,v 1.3 2003/02/28 17:28:52 kim Exp $
> */
> public class VelocityMemorySimple
> extends TestCaseJUnit {
> private static final DiagnosticsIf diag =
> DiagnosticsFact.instance(VelocityMemorySimple.class);
> private static final int ROWS_BETWEEN_DISPLAY = 1000;
> private static final int ROWS_TO_ITERATE = 5 * ROWS_BETWEEN_DISPLAY;
>
> private static long lastTime = -1;
> public VelocityMemorySimple(String name) throws ExceptionBase {
> super(name);
> }
> ///
> private void showInfo(long rowsInserted)
> throws Exception {
> if (rowsInserted==0) {
> System.gc();
> lastTime = System.currentTimeMillis();
> }
>
> if (rowsInserted%ROWS_BETWEEN_DISPLAY == 0) {
> long nowTime = System.currentTimeMillis();
> System.gc();
> diag.info("Ite=" + rowsInserted
> + " Mem free ="
> + java.lang.Runtime.getRuntime().freeMemory()
> + " Mem total="
> + java.lang.Runtime.getRuntime().totalMemory()
> + " Ite/sec.="
> + ((double) 1000*ROWS_BETWEEN_DISPLAY)/(nowTime-lastTime)
> );
> lastTime = nowTime;
> }
> }
> public void testMemory()
> throws Exception {
> try {
> Properties p = new Properties();
>
> p.setProperty("runtime.log.logsystem.class",
>
> "org.apache.velocity.runtime.log.SimpleLog4JLogSystem");
> p.setProperty("runtime.log.logsystem.log4j.category", "VELOCITY");
>
> p.setProperty("resource.manager.logwhenfound", "true");
> p.setProperty("velocimacro.library", "");
> p.setProperty("resource.loader",
> "datasourceglobal, datasourcecustom");
>
> p.setProperty("datasourceglobal.resource.description",
> "Load Templates From java:ExcediaDB Global
> Resources");
> p.setProperty("datasourceglobal.resource.loader.class",
>
[jira] Closed: (VELOCITY-160) Pooled VelocityWriters in VelocityServlet do not release Writer until recycled
[ https://issues.apache.org/jira/browse/VELOCITY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-160. --- > Pooled VelocityWriters in VelocityServlet do not release Writer until recycled > -- > > Key: VELOCITY-160 > URL: https://issues.apache.org/jira/browse/VELOCITY-160 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.3.1-rc2 > Environment: Operating System: All > Platform: All >Reporter: Bill Boland > Assigned To: Velocity-Dev List > Fix For: 1.4 > > > Based on some memory debugging with Tomcat and ServletExec servlet engines, > we > have noticed that the VelocityWriter objects in the VelocityServlet keep a > reference to the OutputStreamWriter when placed into the SimplePool until the > VelocityWriter object is removed from the pool and recycled. The effect of > this retained reference causes the response and request objects to remain in > memeory and, depending on the implementation, the attributes for the request > and response objects remain as well. > By removing the reference to the OutputStreamWriter from the VelocityWriter > (i.e. setting it to null) before placing it back into the pool, the system > will be able to reclaim the request and response objects. Although this would > not be noticed much on a busy system where there are requests exhausting the > pooled objects, when activity drops and many VelocityWriters are retained in > the pool, this can cause large amounts of memory to be wasted until the > VelocityWriter is recycled if request attributes to large objects are still > retained. > In the finally block of the mergeTemplate method, the VelocityWriter could be > recycled with a null value for the Writer *before* being placed into the pool > (or some other *reset* method could be added to the VW): > vw.flush(); > vw.recycle( null ); // or vw.reset(); > writerPool.put(vw); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-417) add log attribute to ant task and "stringUtils" to context
[
https://issues.apache.org/jira/browse/VELOCITY-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-417.
---
> add log attribute to ant task and "stringUtils" to context
> --
>
> Key: VELOCITY-417
> URL: https://issues.apache.org/jira/browse/VELOCITY-417
> Project: Velocity
> Issue Type: Improvement
> Components: Texen
>Reporter: sebastian
> Fix For: 1.5
>
>
> logging.patch: adds a "logFile" attribute
> --- src/java/org/apache/velocity/texen/ant/TexenTask.java.origThu Oct
> 20 15:12:22 2005
> +++ src/java/org/apache/velocity/texen/ant/TexenTask.java Thu Oct 20
> 15:55:07 2005
> @@ -21,6 +21,7 @@
> import java.util.Hashtable;
> import java.util.Iterator;
> import java.util.Map;
> +import java.util.Properties;
>
> import java.io.File;
> import java.io.Writer;
> @@ -136,6 +137,12 @@
> protected boolean useClasspath;
>
> /**
> + * The LogFile (incl. path) to log to.
> + */
> +protected String logFile;
> +
> +
> +/**
> * Path separator.
> */
> private String fileSeparator = System.getProperty("file.separator");
> @@ -253,6 +260,22 @@
> }
>
> /**
> + * Sets the log file.
> + */
> +public void setLogFile(String log)
> +{
> +this.logFile = log;
> +}
> +
> +/**
> + * Gets the log file.
> + */
> +public String getLogFile()
> +{
> +return this.logFile;
> +}
> +
> +/**
> * Set the context properties that will be
> * fed into the initial context be the
> * generating process starts.
> @@ -413,6 +436,11 @@
> ve.setProperty(
> "classpath." + VelocityEngine.RESOURCE_LOADER +
> ".modificationCheckInterval", "2");
> +}
> +
> +if (this.logFile != null)
> +{
> +ve.setProperty(ve.RUNTIME_LOG, this.logFile);
> }
>
> ve.init();
> stringUtils.patch: adds a stringutils obj to the context
> --- src/java/org/apache/velocity/texen/ant/TexenTask.java.origWed Apr
> 14 14:26:42 2004
> +++ src/java/org/apache/velocity/texen/ant/TexenTask.java Thu Oct 20
> 15:09:03 2005
> @@ -568,6 +568,7 @@
> throws Exception
> {
> context.put("now", new Date().toString());
> +context.put("stringUtils", new StringUtils());
> }
>
> /**
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-160) Pooled VelocityWriters in VelocityServlet do not release Writer until recycled
[ https://issues.apache.org/jira/browse/VELOCITY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-160. --- > Pooled VelocityWriters in VelocityServlet do not release Writer until recycled > -- > > Key: VELOCITY-160 > URL: https://issues.apache.org/jira/browse/VELOCITY-160 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.3.1-rc2 > Environment: Operating System: All > Platform: All >Reporter: Bill Boland > Assigned To: Velocity-Dev List > Fix For: 1.4 > > > Based on some memory debugging with Tomcat and ServletExec servlet engines, > we > have noticed that the VelocityWriter objects in the VelocityServlet keep a > reference to the OutputStreamWriter when placed into the SimplePool until the > VelocityWriter object is removed from the pool and recycled. The effect of > this retained reference causes the response and request objects to remain in > memeory and, depending on the implementation, the attributes for the request > and response objects remain as well. > By removing the reference to the OutputStreamWriter from the VelocityWriter > (i.e. setting it to null) before placing it back into the pool, the system > will be able to reclaim the request and response objects. Although this would > not be noticed much on a busy system where there are requests exhausting the > pooled objects, when activity drops and many VelocityWriters are retained in > the pool, this can cause large amounts of memory to be wasted until the > VelocityWriter is recycled if request attributes to large objects are still > retained. > In the finally block of the mergeTemplate method, the VelocityWriter could be > recycled with a null value for the Writer *before* being placed into the pool > (or some other *reset* method could be added to the VW): > vw.flush(); > vw.recycle( null ); // or vw.reset(); > writerPool.put(vw); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-141) can't assign a velocity reference to the return value of a method when the value is null
[ https://issues.apache.org/jira/browse/VELOCITY-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-141. --- > can't assign a velocity reference to the return value of a method when the > value is null > > > Key: VELOCITY-141 > URL: https://issues.apache.org/jira/browse/VELOCITY-141 > Project: Velocity > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.3-rc1 > Environment: Operating System: other > Platform: All >Reporter: Robert Thornton > Assigned To: Velocity-Dev List >Priority: Minor > Fix For: 1.4 > > > I understand this is not a bug, and that it is a documented feature, but I > fail > to see the logic behind preventing the template designer from assigning a > reference to the return value of a method when that method returns null. It > can easily lead to unexpected results unless great care is taken, and it > prevents the use of temporary references within foreach loops. This behavior > is contrary to that of all other templating languages I've seen and there is > not even an adequate explanation for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-147) Version information missing from MANIFEST.MF file.
[ https://issues.apache.org/jira/browse/VELOCITY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-147. --- > Version information missing from MANIFEST.MF file. > -- > > Key: VELOCITY-147 > URL: https://issues.apache.org/jira/browse/VELOCITY-147 > Project: Velocity > Issue Type: Improvement > Components: Build >Affects Versions: 1.3-rc1 > Environment: Operating System: All > Platform: All >Reporter: Rick Kellogg >Priority: Minor > Fix For: 1.5 > > Attachments: LICENSE-fix.patch, MANIFEST-fix.patch > > > Build date and version information should be added to the MANIFEST.MF file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-141) can't assign a velocity reference to the return value of a method when the value is null
[ https://issues.apache.org/jira/browse/VELOCITY-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-141. --- > can't assign a velocity reference to the return value of a method when the > value is null > > > Key: VELOCITY-141 > URL: https://issues.apache.org/jira/browse/VELOCITY-141 > Project: Velocity > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.3-rc1 > Environment: Operating System: other > Platform: All >Reporter: Robert Thornton > Assigned To: Velocity-Dev List >Priority: Minor > Fix For: 1.4 > > > I understand this is not a bug, and that it is a documented feature, but I > fail > to see the logic behind preventing the template designer from assigning a > reference to the return value of a method when that method returns null. It > can easily lead to unexpected results unless great care is taken, and it > prevents the use of temporary references within foreach loops. This behavior > is contrary to that of all other templating languages I've seen and there is > not even an adequate explanation for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-117) modificationCheckInterval is documented with wrong units
[ https://issues.apache.org/jira/browse/VELOCITY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-117. --- > modificationCheckInterval is documented with wrong units > > > Key: VELOCITY-117 > URL: https://issues.apache.org/jira/browse/VELOCITY-117 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 1.3-rc1 > Environment: Operating System: All > Platform: All >Reporter: Chuck Ocheret > Assigned To: Velocity-Dev List >Priority: Minor > Fix For: 1.4 > > > The javadoc for org.apache.velocity.runtime.resource.Resource reports that > modificationCheckInterval is in milliseconds and that > setModificationCheckInterval takes an interval in minutes. Neither is > correct. The truth appears to be that this value is interpreted as seconds. > ~chuck -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-117) modificationCheckInterval is documented with wrong units
[ https://issues.apache.org/jira/browse/VELOCITY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-117. --- > modificationCheckInterval is documented with wrong units > > > Key: VELOCITY-117 > URL: https://issues.apache.org/jira/browse/VELOCITY-117 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 1.3-rc1 > Environment: Operating System: All > Platform: All >Reporter: Chuck Ocheret > Assigned To: Velocity-Dev List >Priority: Minor > Fix For: 1.4 > > > The javadoc for org.apache.velocity.runtime.resource.Resource reports that > modificationCheckInterval is in milliseconds and that > setModificationCheckInterval takes an interval in minutes. Neither is > correct. The truth appears to be that this value is interpreted as seconds. > ~chuck -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-116) Error in Developer Guide
[ https://issues.apache.org/jira/browse/VELOCITY-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-116. --- > Error in Developer Guide > > > Key: VELOCITY-116 > URL: https://issues.apache.org/jira/browse/VELOCITY-116 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 1.3-rc1 > Environment: Operating System: other > Platform: Other >Reporter: Paul Lynch > Assigned To: Velocity-Dev List >Priority: Minor > Fix For: 1.5 > > Attachments: developer-guide.file.patch > > > The developer guide, in the section on "Velocity Configuration Keys and > Values," > says that the default value of resource.loader is "File". Shouldn't that be > "file"? I am using 1.3.0, and configure the location of the templates with > the property "file.resource.loader.path". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-115) Methods cannot be invoked from vm
[
https://issues.apache.org/jira/browse/VELOCITY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-115.
---
> Methods cannot be invoked from vm
> -
>
> Key: VELOCITY-115
> URL: https://issues.apache.org/jira/browse/VELOCITY-115
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: PC
>Reporter: Alexander Veit
> Assigned To: Velocity-Dev List
>Priority: Critical
> Fix For: 1.4
>
>
> Method findMethod(String name, Object[] params) of
> org.apache.velocity.util.introspection.ClassMap
> fails under some circumstances.
> -->
> Twonk twonk = calcDistance( params, parameterTypes ) is null
> -->
> private Twonk MethodMap.calcDistance( Object[] set, Class[] base )
> {
> //...
> if ( !base[i].isAssignableFrom( set[i].getClass() ))
> return null; // place breakpoint here
> //...
> }
> --- IOrder.java ---
> package velocitybug;
> public interface IOrder
> {
> public void say();
> }
> ---
> --- TheOrder.java ---
> package velocitybug;
> public class TheOrder implements IOrder
> {
> public TheOrder()
> {
> }
> public void say()
> {
> System.out.println("Hello");
> }
> }
> -
> --- TheCollection.java ---
> package velocitybug;
> public class TheCollection
> {
> public TheCollection()
> {
> }
>
> public void aWorks(String s, int i)
> {
> System.out.println("a works");
> }
>
> public void bWorks(IOrder o, String s)
> {
> System.out.println("b works");
> }
>
> public void doesNotWork(IOrder o, int i)
> {
> System.out.println("does not work");
> }
> }
> ---
> --- invokeBug ---
> public void invokeBug()
> {
> VelocityContext l_context;
> Templatel_template;
> PrintWriter l_writer;
> try
> {
> Velocity.init("velocity.properties");
> l_context = new VelocityContext();
> l_context.internalPut("TheOrder", new TheOrder());
> l_context.internalPut("TheCollection", new TheCollection
> ());
> l_template = Velocity.getTemplate("VelocityBug.vm");
> l_writer = new PrintWriter(System.out);
> l_template.merge(l_context, l_writer);
> l_writer.flush();
> l_writer.close();
> }
> catch (Exception l_e)
> {
> l_e.printStackTrace();
> }
> }
> ---
> --- VelocityBug.vm ---
> $TheCollection.aWorks("Hello", 4711)
> $TheCollection.bWorks($TheOrder, "World")
> $TheCollection.doesNotWork($TheOrder, 4712)
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-116) Error in Developer Guide
[ https://issues.apache.org/jira/browse/VELOCITY-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed VELOCITY-116. --- > Error in Developer Guide > > > Key: VELOCITY-116 > URL: https://issues.apache.org/jira/browse/VELOCITY-116 > Project: Velocity > Issue Type: Bug > Components: Documentation >Affects Versions: 1.3-rc1 > Environment: Operating System: other > Platform: Other >Reporter: Paul Lynch > Assigned To: Velocity-Dev List >Priority: Minor > Fix For: 1.5 > > Attachments: developer-guide.file.patch > > > The developer guide, in the section on "Velocity Configuration Keys and > Values," > says that the default value of resource.loader is "File". Shouldn't that be > "file"? I am using 1.3.0, and configure the location of the templates with > the property "file.resource.loader.path". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-111) Velocity Macro names can't start with 'set'
[
https://issues.apache.org/jira/browse/VELOCITY-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-111.
---
> Velocity Macro names can't start with 'set'
> ---
>
> Key: VELOCITY-111
> URL: https://issues.apache.org/jira/browse/VELOCITY-111
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: PC
>Reporter: Erik Wright
> Assigned To: Velocity-Dev List
> Fix For: 1.4
>
>
> I created a velocity macro called setDAOFromPrimitive and called it from a
> .vm
> template file.
> --
> #macro ( setDAOFromPrimitive $vmdao $vmcol $vmprim )
> ## ...
> #end
> ## ...
> #setDAOFromPrimitive ("m_dao" $col $ptype)
>
> Parsing the template using velocity generates the following error:
> ---
> 2002-10-23 17:45:00,684 - ResourceManager.getResource() parse exception:
> org.apache.velocity.exception.ParseErrorException:
> Encountered "DAOFromPrimitive" at line 205, column 11.
> Was expecting one of:
> "(" ...
> ...
> ---
> It seems velocity treats any instance of "#set" as a property assignment,
> even
> if the name contains more characters. The workaround is to change the macro
> name.
> BTW I'm using the velocity-1.3.jar that ships with torque-3.0-b4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-115) Methods cannot be invoked from vm
[
https://issues.apache.org/jira/browse/VELOCITY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-115.
---
> Methods cannot be invoked from vm
> -
>
> Key: VELOCITY-115
> URL: https://issues.apache.org/jira/browse/VELOCITY-115
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: PC
>Reporter: Alexander Veit
> Assigned To: Velocity-Dev List
>Priority: Critical
> Fix For: 1.4
>
>
> Method findMethod(String name, Object[] params) of
> org.apache.velocity.util.introspection.ClassMap
> fails under some circumstances.
> -->
> Twonk twonk = calcDistance( params, parameterTypes ) is null
> -->
> private Twonk MethodMap.calcDistance( Object[] set, Class[] base )
> {
> //...
> if ( !base[i].isAssignableFrom( set[i].getClass() ))
> return null; // place breakpoint here
> //...
> }
> --- IOrder.java ---
> package velocitybug;
> public interface IOrder
> {
> public void say();
> }
> ---
> --- TheOrder.java ---
> package velocitybug;
> public class TheOrder implements IOrder
> {
> public TheOrder()
> {
> }
> public void say()
> {
> System.out.println("Hello");
> }
> }
> -
> --- TheCollection.java ---
> package velocitybug;
> public class TheCollection
> {
> public TheCollection()
> {
> }
>
> public void aWorks(String s, int i)
> {
> System.out.println("a works");
> }
>
> public void bWorks(IOrder o, String s)
> {
> System.out.println("b works");
> }
>
> public void doesNotWork(IOrder o, int i)
> {
> System.out.println("does not work");
> }
> }
> ---
> --- invokeBug ---
> public void invokeBug()
> {
> VelocityContext l_context;
> Templatel_template;
> PrintWriter l_writer;
> try
> {
> Velocity.init("velocity.properties");
> l_context = new VelocityContext();
> l_context.internalPut("TheOrder", new TheOrder());
> l_context.internalPut("TheCollection", new TheCollection
> ());
> l_template = Velocity.getTemplate("VelocityBug.vm");
> l_writer = new PrintWriter(System.out);
> l_template.merge(l_context, l_writer);
> l_writer.flush();
> l_writer.close();
> }
> catch (Exception l_e)
> {
> l_e.printStackTrace();
> }
> }
> ---
> --- VelocityBug.vm ---
> $TheCollection.aWorks("Hello", 4711)
> $TheCollection.bWorks($TheOrder, "World")
> $TheCollection.doesNotWork($TheOrder, 4712)
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VELOCITY-111) Velocity Macro names can't start with 'set'
[
https://issues.apache.org/jira/browse/VELOCITY-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-111.
---
> Velocity Macro names can't start with 'set'
> ---
>
> Key: VELOCITY-111
> URL: https://issues.apache.org/jira/browse/VELOCITY-111
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: PC
>Reporter: Erik Wright
> Assigned To: Velocity-Dev List
> Fix For: 1.4
>
>
> I created a velocity macro called setDAOFromPrimitive and called it from a
> .vm
> template file.
> --
> #macro ( setDAOFromPrimitive $vmdao $vmcol $vmprim )
> ## ...
> #end
> ## ...
> #setDAOFromPrimitive ("m_dao" $col $ptype)
>
> Parsing the template using velocity generates the following error:
> ---
> 2002-10-23 17:45:00,684 - ResourceManager.getResource() parse exception:
> org.apache.velocity.exception.ParseErrorException:
> Encountered "DAOFromPrimitive" at line 205, column 11.
> Was expecting one of:
> "(" ...
> ...
> ---
> It seems velocity treats any instance of "#set" as a property assignment,
> even
> if the name contains more characters. The workaround is to change the macro
> name.
> BTW I'm using the velocity-1.3.jar that ships with torque-3.0-b4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
