Re: svn commit: r491783 - in /velocity/engine/trunk/build: build.properties
Le mercredi 03 janvier 2007 à 00:50 +, Henning P. Schmiedehausen a
écrit :
[EMAIL PROTECTED] writes:
Hi,
while I'm basically +1 for the patch (lazy consensus), can you please
document each of the properties inside build.properties. ATM they seem
to be self-explanatory but in six months, we might wonder about the
interactions...
Ok, I'll add details.
Does the default setting break Gump?
That's a very good question. It's impossible to test that right now
since commons-lang is broken since yesterday. Plus, I'm now worried it
might even be worse: it could not break Gump but only change the way it
works (by not using @@DATE@@ versions of the dependencies). Since there
already are some properties that are present in build.properties and
overridden in Gump's velocity-engine.xml I think it should be ok, but is
there anyway to check that?
By the way, engine test is broken on my box (Linux, Java 1.5.0_06-b05):
Didn't see introspector cache dump.
junit.framework.AssertionFailedError: Didn't see introspector cache
dump.
at
org.apache.velocity.test.ClassloaderChangeTestCase.testClassloaderChange(ClassloaderChangeTestCase.java:136)
Claude
Best regards
Henning
Author: cbrisson
Date: Tue Jan 2 04:21:11 2007
New Revision: 491783
URL: http://svn.apache.org/viewvc?view=revrev=491783
Log:
skip.jar.loading and force.jar.loading now have a consistent behaviour
(VELOCITY-502)
Modified:
velocity/engine/trunk/build/build.properties
velocity/engine/trunk/build/download.xml
Modified: velocity/engine/trunk/build/build.properties
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/build/build.properties?view=diffrev=491783r1=491782r2=491783
==
--- velocity/engine/trunk/build/build.properties (original)
+++ velocity/engine/trunk/build/build.properties Tue Jan 2 04:21:11 2007
@@ -68,6 +68,10 @@
test.haltonerror= true
test.haltonfailure= true
+#downloading dependency jars
+skip.jar.loading= false
+force.jar.loading= true
+
# Building the distribution
dist.root= ${build.dir}/dist
dist.dir= ${dist.root}/${final.name}
Modified: velocity/engine/trunk/build/download.xml
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/build/download.xml?view=diffrev=491783r1=491782r2=491783
==
--- velocity/engine/trunk/build/download.xml (original)
+++ velocity/engine/trunk/build/download.xml Tue Jan 2 04:21:11 2007
@@ -45,7 +45,20 @@
antcall target=junit-download /
/target
- target name=http-download unless=skip.jar.loading
+ target name=http-download
+condition property=skip-download
+ or
+istrue value=${skip.jar.loading}/
+and
+ isfalse value=${force.jar.loading}/
+ available
file=${build.lib}/${download.jarname}-${download.jarversion}.jar/
+/and
+ /or
+/condition
+antcall target=do-http-download/
+ /target
+
+ target name=do-http-download unless=skip-download
setproxy proxyhost=${proxy.host} proxyport=${proxy.port}/
get
src=${repo.url}/${download.jarname}/jars/${download.jarname}-${download.jarversion}.jar
dest=${build.lib}/${download.jarname}-${download.jarversion}.jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-149) allow for deeply nested macro calls
[
https://issues.apache.org/jira/browse/VELOCITY-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461924
]
Christoph Reck commented on VELOCITY-149:
-
The multi-line directives of (upcoming) 1.5 release and the better
quote-escaping (using a doubled quote in the quoted string), seems to
make this request obsolete.
The following looks akward to me:
#macro1(foo-#macro2(bar)-baz)
Can someone tell me in which programming language this would be possible?
Going with normal programming practices, you would unwrap this into:
#set( $bar = #macro2('bar') )
#macro1(foo-${bar}-baz)
OTOH, this requests seems related to
http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11751.html which
could be more useful than the above akward assembly.
allow for deeply nested macro calls
---
Key: VELOCITY-149
URL: https://issues.apache.org/jira/browse/VELOCITY-149
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.3-rc1
Environment: Operating System: All
Platform: All
Reporter: Ralf Hauser
Priority: Minor
Fix For: 1.5
currently, it appears that more than two levels get almost unfeasible.
see also http://sourceforge.net/mailarchive/message.php?msg_id=4015929
Being able to do multi-line string literals or macro arguments is probably a
related idea (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17803)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://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]
Re: [jira] Created: (VELOCITY-509) Add new directive #evaluate
No, the #evaluate directive is to be used as it the following example: #set( $error = $i18n_tool.getMessage(ERROR123) ) #evaluate( $error )## reder by merging with context It something like the #parse directive, but the content comes from a string and not a file. :) Christoph Geir Magnusson Jr. wrote: Do you mean $foo = #foreach($a in $b) .. #end ? If so, why not just do it that way, rather than add a new directive? geir On Jan 2, 2007, at 11:47 PM, Will Glass-Husain (JIRA) wrote: Add new directive #evaluate --- Key: VELOCITY-509 URL: https://issues.apache.org/jira/browse/VELOCITY-509 Project: Velocity Issue Type: New Feature Components: Engine Affects Versions: 1.5 beta2 Reporter: Will Glass-Husain Priority: Minor Fix For: 1.6 On a separate issue (VELOCITY-504) we came up with the idea of a new directive, #evaluate. Basically, it would act just like Velocity.evaluate(). Users are always asking for this capability (internal evaluation). Usually we tell them to use a tool. Instead, we should just put in a simple directive that would evaluate a VTL string using the current context. Incidentally, this should be the current local context, e.g. if inside a macro or a foreach loop (or worse, both) it should use that context. See VELOCITY-504 for why this is needed. --This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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] - 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-149) allow for deeply nested macro calls
[ https://issues.apache.org/jira/browse/VELOCITY-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461957 ] Will Glass-Husain commented on VELOCITY-149: Is the Macro with Body Content idea (from the email) in JIRA somewhere? That seems pretty cool. allow for deeply nested macro calls --- Key: VELOCITY-149 URL: https://issues.apache.org/jira/browse/VELOCITY-149 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.3-rc1 Environment: Operating System: All Platform: All Reporter: Ralf Hauser Priority: Minor Fix For: 1.5 currently, it appears that more than two levels get almost unfeasible. see also http://sourceforge.net/mailarchive/message.php?msg_id=4015929 Being able to do multi-line string literals or macro arguments is probably a related idea (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17803) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
Re: [RESULT] [VOTE] Release VelocityTools 1.3-beta1
Hmm. I didn't notice the beta directory. Yeah, i can move 1.3-beta1, but i don't approve of the distinction. Alphas and betas are releases. If we vote on it and announce it (as i will as soon as i can get my feet under myself after the holidays and update all the download links), then it is a release. So, before i move it over, let's get our nomenclature straight here and change the release folder to stable or final or something like that, so that it is clear that that is the place to put and find all final releases. On 1/2/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: (First: Happy new year, Velocity folks!) Hi Nathan, I somehow missed that you have put the 1.3 beta-1 release archives onto www.apache.org/dist. As this is a beta version and not a release, the location is a bit unfortunate. I'd very much prefer if you could move the 1.3-beta-1 out of the release directory and into beta/1.3-beta1, similar to the engine (which has also a beta and a release directory). And also restore the current links back to Tools 1.2. The offical stable release is currently still 1.2, so we should not upset people downloading it. :-) Thank you Henning [...] And the final tally is... PMC +1's - Nathan Bubna - Will Glass-Husain - Marino A Jonsson - Henning Schmiedehausen Committer +1's - Claude Brisson Feedback - Claude wants the logging issue better documented - Henning wants BC tests for Struts 1.2 and maybe Struts 1.1 My plan - I'm away from my home desk, but i'll try to get the docs updated a bit more before rolling a release in the next few days. Depends on the flakiness of the wifi here. :) Once the beta is out, i plan to work on the remaining bugs scheduled for 1.3 and updating the documentation with the new features and changes. Assuming there are no major issues found, i'd love to get an RC out by January's end. Help would be greatly appreciated! :) Especially from any who think it's about time we get this version out. ;-) I'll admit, i'm largely excited to get this out so i can start working on the cool stuff i want to do in 2.0. But i also want 1.3 to be of better quality than the previous versions since it may take a while to get 2.0 in shape. So, i'd really appreciate if ya'll can try this out and perhaps help a bit too. :) On 12/21/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 12/21/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: Ok, i've got all the dependencies upgraded. The ant build system seems to be working great. I've attempted to get the Gump build working again, but that shouldn't hold up a release anyway. So, i think we're ready for a beta of VelocityTools 1.3: [X] +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'd like to see some tests to build it with 1.2.x and maybe 1.1, too because sometimes people are stuck on these Struts versions. Apart from that: Great work!) I'd love to see that too. :) However, i'm no longer using VelocityStruts. My time/interest in that part is very limited. Here's the good news though: we didn't have to change any tool code to make the VelocityStruts tools work with 1.3. This means they're definitely still compatible with 1.2 at this point. If/when i get around to https://issues.apache.org/jira/browse/VELTOOLS-58, then i'll try to remember to test against Struts 1.2. No promises though. I have no idea about Struts 1.1 compatibility, and i'm not sure i care to support anyone that many years behind. They can keep using VelocityTools 1.1 just fine. Otherwise, folks are welcome to volunteer to help with that! 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 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, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy 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
Re: #evaluate
The more canonical example for an evaluate tool (or directive) is
being ably to dynamically decide what method to call on a particular
reference. So, something along the lines of:
#if( $this $that )
#set( $method = $foo )
#else
#set( $method = $bar )
#end
$render.eval( \${someRef}.${method} )
Though, Christoph's example gets to the same point quicker.
While i am quite fine with providing a tool or a directive for
advanced users to do this, i really don't think it's practical,
necessary, or wise to bend over backwards to support this sort of
thing. So, i'm not even sure i'm ready to automatically include such
a directive in the default directive.properties, much less add some
new-fangled syntax for doing such things. At least an #evaluate
directive wouldn't really be growing the VTL language.
And as far as adding on optional parameter to narrow the context for
such evaluations, i think i can say with great confidence that YAGNI.
I don't think most people even need #evaluate, much less one with
such fine-grained context control.
On 1/3/07, Will Glass-Husain [EMAIL PROTECTED] wrote:
[I'm changing the subject line-- I kept looking for this discussion in JIRA]
Great way of way of framing this, Christopher. Thinking about
#evaluate as a companion to #include and #parse makes me realize this
new proposed directive fits within the Velocity approach.
Another idea is to have an optional argument with a map that would
serve as a context.
#evaluate(hello from $name,{name:Will})
WILL
On 1/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
No, the #evaluate directive is to be used as it the following example:
#set( $error = $i18n_tool.getMessage(ERROR123) )
#evaluate( $error )## reder by merging with context
It something like the #parse directive, but the content comes
from a string and not a file.
:) Christoph
Geir Magnusson Jr. wrote:
Do you mean
$foo = #foreach($a in $b) .. #end
?
If so, why not just do it that way, rather than add a new directive?
geir
On Jan 2, 2007, at 11:47 PM, Will Glass-Husain (JIRA) wrote:
Add new directive #evaluate
---
Key: VELOCITY-509
URL: https://issues.apache.org/jira/browse/VELOCITY-509
Project: Velocity
Issue Type: New Feature
Components: Engine
Affects Versions: 1.5 beta2
Reporter: Will Glass-Husain
Priority: Minor
Fix For: 1.6
On a separate issue (VELOCITY-504) we came up with the idea of a new
directive, #evaluate. Basically, it would act just like
Velocity.evaluate().
Users are always asking for this capability (internal evaluation).
Usually we tell them to use a tool. Instead, we should just put in
a simple directive that would evaluate a VTL string using the current
context.
Incidentally, this should be the current local context, e.g. if inside
a macro or a foreach loop (or worse, both) it should use that
context. See VELOCITY-504 for why this is needed.
--This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: https://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]
-
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]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
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]
1.5 Release Timeline
Hi All, I know its the perennial question, but do you have a feeling for the release date for Velocity 1.5, am working up to a minor Click release and want to know if I should have it follow the Velocity 1.5 release. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.5 Release Timeline
I'm not sure a beta3 will be necessary unless there are further delays. Looking at JIRA, all replicatable bugs have been resolved and all issues with patches (save 1) have been added. We should go straight for rc1. And yes, I'd be glad to be spokesperson for press inquiries. Henning and I attended a workshop at ApacheCon on publicizing open source projects-- having a single spokesperson for the press was one of the key recommendations. WILL On 1/3/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Malcolm Edgar [EMAIL PROTECTED] writes: Hi All, I know its the perennial question, but do you have a feeling for the release date for Velocity 1.5, am working up to a minor Click release and want to know if I should have it follow the Velocity 1.5 release. You are not the only one. Arnaud (of Maven 1 fame) is nagging on IRC ;-) Well, I will on holidays starting February 2nd. And I would love to get it out before that. Considering the fact that we will need ~10 days for the release procedure, we should set us a timeline for the CfV. I'd suggest the 22th of January for the CfV. If we want to get out another beta, we must do this no later than a week before. Let's say the 15th for CfV for a possible beta3/rc1. Alternatively someone else will do the release in February / I can do it mid-March (which I'd really like to avoid). Everything that is not fixed by then will miss the release and go for 1.6 which I'd expect to come out no later than three months afterwards. Will: What we would need is to start to liason with the PRC for a press release and probably a contact person for inquiries. With me out of the picture for four weeks, I'd like to ask you to volunteer for that. ;-) Opinions? 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 Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
