svn commit: r365328 - /jakarta/velocity/core/trunk/src/test/org/apache/velocity/test/MultipleFileResourcePathTestCase.java
Author: wglass
Date: Mon Jan 2 02:43:03 2006
New Revision: 365328
URL: http://svn.apache.org/viewcvs?rev=365328view=rev
Log:
remove redundant constants
Modified:
jakarta/velocity/core/trunk/src/test/org/apache/velocity/test/MultipleFileResourcePathTestCase.java
Modified:
jakarta/velocity/core/trunk/src/test/org/apache/velocity/test/MultipleFileResourcePathTestCase.java
URL:
http://svn.apache.org/viewcvs/jakarta/velocity/core/trunk/src/test/org/apache/velocity/test/MultipleFileResourcePathTestCase.java?rev=365328r1=365327r2=365328view=diff
==
---
jakarta/velocity/core/trunk/src/test/org/apache/velocity/test/MultipleFileResourcePathTestCase.java
(original)
+++
jakarta/velocity/core/trunk/src/test/org/apache/velocity/test/MultipleFileResourcePathTestCase.java
Mon Jan 2 02:43:03 2006
@@ -37,20 +37,6 @@
*/
public class MultipleFileResourcePathTestCase extends BaseTestCase
{
- /**
- * VTL file extension.
- */
-private static final String TMPL_FILE_EXT = vm;
-
-/**
- * Comparison file extension.
- */
-private static final String CMP_FILE_EXT = cmp;
-
-/**
- * Comparison file extension.
- */
-private static final String RESULT_FILE_EXT = res;
/**
* Path for templates. This property will override the
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r365339 - /jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java
Author: wglass
Date: Mon Jan 2 04:42:18 2006
New Revision: 365339
URL: http://svn.apache.org/viewcvs?rev=365339view=rev
Log:
prevent NPE when velocimacro.library.autoreload=true and there is no global
velocimacro library
Modified:
jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java
Modified:
jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java?rev=365339r1=365338r2=365339view=diff
==
---
jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java
(original)
+++
jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java
Mon Jan 2 04:42:18 2006
@@ -390,7 +390,7 @@
* template is one of the library templates
*/
-if ( getAutoload() )
+if ( getAutoload() (macroLibVec != null) )
{
/*
* see if this is a library template
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-146) Macros not evaluated on the first attempt with #parse
[ http://issues.apache.org/jira/browse/VELOCITY-146?page=all ] Will Glass-Husain updated VELOCITY-146: --- Bugzilla Id: (was: 17669) Summary: Macros not evaluated on the first attempt with #parse (was: Macros not evaluated on the first attempt) Macros not evaluated on the first attempt with #parse - Key: VELOCITY-146 URL: http://issues.apache.org/jira/browse/VELOCITY-146 Project: Velocity Type: Improvement Components: Build Versions: 1.5 Environment: Operating System: All Platform: PC Reporter: Sami Leino Priority: Minor Fix For: 1.5 Attachments: wml_templates.zip I have noticed that sometimes macros do not get evaluated after Velocity has just been started. A subsequent request for the same resource produces a valid document, where macros are now correctly evaluated. Here's an example: I have a WAP-Mail webapp, which runs on Tomcat 3.3a. It uses Velocity to render the content, and the Velocity versions I have used are 1.2- dep, 1.3-dep and 1.3.1-dep. This problem occurs with all of these versions. The first request should produce a message list (there's an autologin feature, so the message list page is the first one being accessed). Here's the most relevant part of the content: -- pFolder: INBOXbr//p p br/bDate: 05.03 11:16/b br/Sender: John Doe br/Subject: a href=/wapmail/message/show/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-velocity Wiki] Update of FrontPage by WillGlassHusain
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-velocity Wiki for change notification. The following page has been changed by WillGlassHusain: http://wiki.apache.org/jakarta-velocity/FrontPage -- === Architecture Discussions Debates === Discussions/proposals/votes concerning various issues around the future architecture of Velocity. + * MacroIssues * VelocityWhitespaceGobbling * VelocityLogging * VelocityNullSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-velocity Wiki] Update of MacroIssues by WillGlassHusain
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-velocity Wiki
for change notification.
The following page has been changed by WillGlassHusain:
http://wiki.apache.org/jakarta-velocity/MacroIssues
The comment on the change is:
new file
New page:
=== Macro bug fixes / enhancements ===
some notes by Will [EMAIL PROTECTED].
I'm starting to look into the remain bug fix/enhancements for the 1.5 release.
Not surprisingly, many of the remaining issues are all pretty subtle. I
thought I'd publically share a few notes on macros.
Here's a catalog of the open macro-related issues targeted for 1.5.
* http://issues.apache.org/jira/browse/VELOCITY-277 Macros in #parsed files
are not refreshed when including page is refreshed
* http://issues.apache.org/jira/browse/VELOCITY-362 Can't load macros in file
loaded with #parse
* http://issues.apache.org/jira/browse/VELOCITY-146 Macros not evaluated on
the first attempt with #parse
* http://issues.apache.org/jira/browse/VELOCITY-24 Calls to local macros not
always made when template caching is off
* http://issues.apache.org/jira/browse/VELOCITY-82 VM libs will not
autoreload if unparseable at Velocity startup
---
Most of these issues stem from how Velocity stores macros. Macros can be
stored either at a global level
or on a per-template level. This is controlled by the config key
velocimacro.permissions.allow.inline.local.scope, which is
false by default. (i.e. all macros are part of global scope). See the
[http://jakarta.apache.org/velocity/docs/developer-guide.html#Velocity%20Configuration%20Keys%20and%20Values
developer's guide].
This means that the following common-sense use case (referenced in
VELOCITY-277, VELOCITY-362, and VELOCITY-136) just doesn't work.
file1.vm
{{{
#parse(macros.txt)
#NewMacro()
}}}
macros.txt
{{{
#macro(NewMacro) do something #end
}}}
Here's why. Case 1. If velocimacro.permissions.allow.inline.local.scope is
true, then #!NewMacro is
defined in macros.txt but not file1.vm. Thus the macro is not available
for use.
Case 2. If velocimacro.permissions.allow.inline.local.scope is false, then
then #!NewMacro is defined
globally and available from all templates. This seems like a good idea
but is impractical in practice for the following reasons.
* First of all, it doesn't work. Hence the first three bugs. They are
technically not bugs since this behavior is
[http://jakarta.apache.org/velocity/docs/user-guide.html#Velocimacro%20Miscellany
documented], though that's difficult to find.
* Currently macros are evaluated at parse time while #parse is evaluated at
runtime. (allowing the template to dynamically
choose a page to include). That's why the macro is not picked up by the
#parse.
* Even if we fix this, there's a threading problem and a namespace problem.
This macro is available to any template.
If a website has hundreds or thousands of templates, there's no guarantee that
another page hasn't defined a macro with
the same name which could be loaded into the same common name space
unexpectedly. The results could be very hard to debug.
Proposed Solution: Add a new mode for macros. (really, this should be the
default in the future), which is request based. When a
macro is defined in a page, it should be follow the execution of the page, be
available in any subpages called with #parse
and be available to a calling page that has called this with #parse. However,
the macro shouldn't interfere with the global
namespace or any non-related templates.
Open issues / discussion points -
* Can this be done while preserving Velocity's high-performance template
caching?
* If we add a new scope for macros, is this backwards compatible? (assuming
we allow old modes to continue to work).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-277) macros in #parsed files are not refreshed when including page is refreshed
[ http://issues.apache.org/jira/browse/VELOCITY-277?page=comments#action_12361525 ] Will Glass-Husain commented on VELOCITY-277: I added some thoughts on resolving this to the Wiki. http://wiki.apache.org/jakarta-velocity/MacroIssues macros in #parsed files are not refreshed when including page is refreshed -- Key: VELOCITY-277 URL: http://issues.apache.org/jira/browse/VELOCITY-277 Project: Velocity Type: Bug Components: Build Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Tim White Priority: Critical Fix For: 1.5 If a template #parses a file containing velocimacros, changes those macros do not make it into the including template. This is true whether the file is included via the library property or via #parse. Although there is the velocimacro.library.autoreload property, it is not for use in production according to the documentation - and cannot be used with template caching. Also, often, macros included via #parse do not pick up their macros the first time they are compiiled. And with template caching they are only ever called once, this leads to situations where changes in templates that include macros and are cached do not function in production. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-146) Macros not evaluated on the first attempt with #parse
[ http://issues.apache.org/jira/browse/VELOCITY-146?page=comments#action_12361526 ] Will Glass-Husain commented on VELOCITY-146: I added some thoughts on resolving this to the Wiki. http://wiki.apache.org/jakarta-velocity/MacroIssues Macros not evaluated on the first attempt with #parse - Key: VELOCITY-146 URL: http://issues.apache.org/jira/browse/VELOCITY-146 Project: Velocity Type: Improvement Components: Build Versions: 1.5 Environment: Operating System: All Platform: PC Reporter: Sami Leino Priority: Minor Fix For: 1.5 Attachments: wml_templates.zip I have noticed that sometimes macros do not get evaluated after Velocity has just been started. A subsequent request for the same resource produces a valid document, where macros are now correctly evaluated. Here's an example: I have a WAP-Mail webapp, which runs on Tomcat 3.3a. It uses Velocity to render the content, and the Velocity versions I have used are 1.2- dep, 1.3-dep and 1.3.1-dep. This problem occurs with all of these versions. The first request should produce a message list (there's an autologin feature, so the message list page is the first one being accessed). Here's the most relevant part of the content: -- pFolder: INBOXbr//p p br/bDate: 05.03 11:16/b br/Sender: John Doe br/Subject: a href=/wapmail/message/show/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
request for comments on Macro issues
I posted a little note about the JIRA issues on macros on the wiki http://wiki.apache.org/jakarta-velocity/MacroIssues Once I dug into these issues, I realized the scope of macros seems rather odd. Specifically, various users have complained that you can't stick macros in a file called by #parse (I've run into this myself). This is documented but still rather unintuititive. The recommended action is to put such macros in a library, but that may not be feasible with a large heterogenous library of templates. (or a case where template writers do not have control of the environment). What I realized is that this is fundamentally due to a design issue rather than a bug. Would appreciate any comments on this interpretation and my proposed approach to solve this. Thanks, WILL
RuntimeExceptions
First, happy new year to the Velocity developer community... I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through. * In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this). * Llewelyn Falco created a TestableUberspect which interrupted processing upon an invalid method call. * There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call. I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices. (1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something. (2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch). (3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through). To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's? Appreciate other thoughts... Best, WILL ___ Forio Business Simulations Will Glass-Husain phone (415) 440-7500 x89 mobile (415) 235-4293 [EMAIL PROTECTED] www.forio.com
Re: RuntimeExceptions
+1 on Option #3. I think this is now accepted as a best practice with Java error handling. regards Malcolm Edgar On 1/3/06, Will Glass-Husain [EMAIL PROTECTED] wrote: First, happy new year to the Velocity developer community... I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through. * In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this). * Llewelyn Falco created a TestableUberspect which interrupted processing upon an invalid method call. * There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call. I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices. (1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something. (2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch). (3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through). To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's? Appreciate other thoughts... Best, WILL ___ Forio Business Simulations Will Glass-Husain phone (415) 440-7500 x89 mobile (415) 235-4293 [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RuntimeExceptions
Hi Will, +1 on Option #3. I think this is now accepted as a best practice with Java error handling. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RuntimeExceptions
On Tue, 2006-01-03 at 08:18 +1100, Malcolm Edgar wrote: +1 on Option #3. I think this is now accepted as a best practice with Java error handling. Yes, please... it would make life with Velocity a lot easier! Regards, Peter PS: any ideas how I should torture students who handle exceptions with empty catch blocks? ;-) It's quite common. -- URBAN Peter, Ph.D. Japan Advanced Institute of Science and Technology (JAIST) Grad. School of Information Science, office I-61 1-1 Asahidai, Nomi, Ishikawa, 923-1292, Japan email: [EMAIL PROTECTED] phone: +81 (761) 51 1254 web: www.jaist.ac.jp/~urban fax: +81 (761) 51 1149 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r365508 - /jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/RuntimeConstants.java
Author: wglass Date: Mon Jan 2 17:18:13 2006 New Revision: 365508 URL: http://svn.apache.org/viewcvs?rev=365508view=rev Log: Fix typo in comments Modified: jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/RuntimeConstants.java Modified: jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/RuntimeConstants.java URL: http://svn.apache.org/viewcvs/jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/RuntimeConstants.java?rev=365508r1=365507r2=365508view=diff == --- jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/RuntimeConstants.java (original) +++ jakarta/velocity/core/trunk/src/java/org/apache/velocity/runtime/RuntimeConstants.java Mon Jan 2 17:18:13 2006 @@ -234,7 +234,7 @@ /** * The codeeventhandler.methodexception.class/code property * specifies a list of the [EMAIL PROTECTED] - * org.apache.velocity.app.event.MethoExceptionEventHandler} + * org.apache.velocity.app.event.MethodExceptionEventHandler} * implementations to use. */ public static final String EVENTHANDLER_METHODEXCEPTION = eventhandler.methodexception.class; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r365509 - in /jakarta/velocity/core/trunk/xdocs: changes.xml changes14.xml docs/changes.xml
Author: wglass Date: Mon Jan 2 17:22:48 2006 New Revision: 365509 URL: http://svn.apache.org/viewcvs?rev=365509view=rev Log: Updated change.xml file in maven format with all changes to date for 1.5. (in gradual preparation for 1.5 release). Moved changelog for 1.4 and earlier to separate file. Added: jakarta/velocity/core/trunk/xdocs/changes14.xml - copied, changed from r365327, jakarta/velocity/core/trunk/xdocs/docs/changes.xml Removed: jakarta/velocity/core/trunk/xdocs/docs/changes.xml Modified: jakarta/velocity/core/trunk/xdocs/changes.xml Modified: jakarta/velocity/core/trunk/xdocs/changes.xml URL: http://svn.apache.org/viewcvs/jakarta/velocity/core/trunk/xdocs/changes.xml?rev=365509r1=365508r2=365509view=diff == --- jakarta/velocity/core/trunk/xdocs/changes.xml (original) +++ jakarta/velocity/core/trunk/xdocs/changes.xml Mon Jan 2 17:22:48 2006 @@ -23,14 +23,322 @@ body release version=1.5-dev date=in Subversion - action type=fix dev=henning issue=VELOCITY-424 due-to=Malcom Edgar + + action type=add dev=wglass issue=VELOCITY-425 due-to=Llewellyn Falco +Wrapped exceptions now have Cause property set on JDK 1.4. (note that Velocity +continues to run under JDK 1.3). + /action + + action type=fix dev=wglass issue=VELOCITY-418 due-to=Jason Weinstein +When Velocity is initialized, default.properties stream was not being closed. This + made it difficult to undeploy webapps on Windows with Velocity unpacked. + /action + + action type=fix dev=wglass issue=VELOCITY-151 due-to=Kirk Wolf +Upgraded to latest commons collection, fixing problem with non-recognition +of configuration file encoding in rare circumstances. + /action + + action type=fix dev=wglass issue=VELOCITY-370 due-to=Reggie Riser +The Introspector could throw a NPE when a parameter to an overloaded method was null. + /action + + action type=fix dev=wglass issue=VELOCITY-381 due-to=Llwellyn Falco and Dan Powell +If toString() returned null in a silent reference then null was displayed. + /action + + action type=fix dev=wglass issue=VELOCITY-359 due-to= +Fixed bug in which empty body for #if (e.g. code#if(some expression)#end/code +caused ParseException. + /action + + action type=add dev=wglass issue=VELOCITY-222 due-to= +Added javacc task to build.xml simplifying modification process +for editing syntax files. + /action + + action type=fix dev=wglass issue=VELOCITY-374 due-to= +Velocity Engine was throwing NPE when used without a call to +init(). Now gives a more meaningful exception message. + /action + + action type=update dev=wglass issue=VELOCITY-404 due-to=Llewellyn Falco +Fixed problem with Uberspect Info class being created incorrectly. +Added template name to Info allowing better error reporting. + /action + + action type=update dev=wglass issue= due-to= +Numerous improvements to the documentation. Reorganized table of +contents, moved community content to the Wiki, added article on using +Velocity in web applications. + /action + + action type=update dev=wglass issue=VELOCITY-350 due-to= +When testing objects in VTL for equality, if both objects are a number, use +number equality. If both objects are the same class, use the equals method. +New behavior: If objects are different classes, compare the String +representation of both objects rather than logging an error. + /action + + action type=fix dev=wglass issue=VELOCITY-272 due-to= +Velocity would give error when last line of file was a ## comment. + /action + + action type=update dev=wglass issue=VELOCITY-412 due-to=Malcolm Edgar +Added method to retrieve application attributes. + /action + + action type=update dev=wglass issue=VELOCITY-196 due-to= +Velocity now searches in the current thread's context classloader +before the system classloader for all templates loaded with the +ClasspathResourceLoader and for all user-defined ResourceLoaders, +introspectors, event handlers, etc. +A typical use for this is to have Velocity in the application +container classpath while keeping templates and plugins in the +webapp classpath. + /action + + action type=update dev=wglass issue= due-to=Thomas Veith +#set now sets references to null when required. For backwards +compatibility this must be enabled by setting the configuration key +codedirective.set.null.allowed/code to true. + /action + + action type=add dev=wglass issue= due-to= +New optional event handler that escapes all references. +Regular
change log
Hi, As it seems there's an emerging consensus we should move to a maven generated site for the 1.5 release (keeping ant docs for personal documentation generation), I've entered all 1.5 changes into a maven format changelog. I like the format of the new changelog-- it's a bit more structured. It will look something like this. http://jakarta.apache.org/turbine/turbine/development/turbine-2.3/changes-report.html Rather than migrate old change logs to the new format, I moved the change items for version 1.4 and earlier into xdocs\change14.xml. Question for Henning and others... * Can we have the changes report have text at the top For changes for versions and earlier, click here? * If so, should we make ant docs ignore the file change.xml and change14.xml Any comments on this? Best, WILL
[jira] Resolved: (VELOCITY-410) Revise changelog.xml
[ http://issues.apache.org/jira/browse/VELOCITY-410?page=all ] Will Glass-Husain resolved VELOCITY-410: Resolution: Fixed updated the maven change file. When we switch to a maven site this will be well-structured and up-to-date Revise changelog.xml Key: VELOCITY-410 URL: http://issues.apache.org/jira/browse/VELOCITY-410 Project: Velocity Type: Improvement Components: Documentation Versions: 1.4 Reporter: Will Glass-Husain Assignee: Will Glass-Husain Priority: Minor Fix For: 1.5 This is a reminder - we need to update the changelog before the 1.5-beta release. I'm a little frustrated with the format. I've been thinking of doing something a bit more structured (like the Tomcat change docs). The current version is hard to read at a glance. Specific changes I'd like to see: * Fix release numbers (the headings appear to be one release off) * Clearly differentiate enhancements from bug fixes * Have a common format to note who provided patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
development status
Hi, Just a quick note on status to all interested parties. Progress continues in fits and starts to the 1.5 release following the Road Map (but having missed the target dates). I'd hoped to have my tasks done last month but an overload of project work wore me down (multiple simultaneous deadlines are a killer). http://wiki.apache.org/jakarta-velocity/RoadMap Henning and I had a chance to chat at ApacheCon and throw ideas around. I think it's safe to release 1.5-beta once we have the revised Maven site ready (Henning is working on this), the changelog updated (done), and all 1.5-targeted improvements and features resolved (all 3 items on my plate). I think we should be able to do this in the next couple of weeks, and then call for a release vote on 1.5-beta. After that there's about 20 bugs (really just about 10 with duplicate cases). Some are pretty subtle but it'd be nice to fix them all before calling for a vote on the 1.5 release. As always, welcome comments, suggestions and patches. Cheers, WILL
