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=rev&rev=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=diff&rev=491783&r1=491782&r2=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=diff&rev=491783&r1=491782&r2=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 @@
> >
> >
> >
> >-
> >+
> >+
> >+
> >+
> >+
> >+
> >+ >file="${build.lib}/${download.jarname}-${download.jarversion}.jar"/>
> >+
> >+
> >+
> >+
> >+
> >+
> >+
> >
> > > 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
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]
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: #evaluate
[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]
Re: #evaluate
On Jan 3, 2007, at 9:23 AM, Will Glass-Husain 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.
So would having a syntactical device to do it...
Another idea is to have an optional argument with a map that would
serve as a context.
#evaluate("hello from $name",{"name":"Will"})
Well, you'd probably want it to be anything appropriate, including a
Context :)
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]
Re: #evaluate
That makes sense. Maps, anything implementing get/put, and Context objects.
WILL
On 1/3/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Jan 3, 2007, at 9:23 AM, Will Glass-Husain 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.
So would having a syntactical device to do it...
>
> Another idea is to have an optional argument with a map that would
> serve as a context.
>
> #evaluate("hello from $name",{"name":"Will"})
Well, you'd probably want it to be anything appropriate, including a
Context :)
>
> 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]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
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: [EMAI
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]
[jira] Resolved: (VELOCITY-504) Call to evaluate inside of macro fails with 1.5 beta2
[ https://issues.apache.org/jira/browse/VELOCITY-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved VELOCITY-504. - Resolution: Won't Fix Well, there is not much that I can add. Your analysis is spot on and basically VELOCITY-285 and this report show two sides of the same medal. I like the idea of #evaluate(), however I don't think that it will (or should) make the boat for 1.5. Maybe this is a good reason to have an 1.6 really soon. I think the current behaviour (having the loop variable as a local) is consistent with most other programming languages (especially Java... ;-) ), so I'd say "won't fix" is the right resolution. Thanks for digging into this. > Call to evaluate inside of macro fails with 1.5 beta2 > - > > Key: VELOCITY-504 > URL: https://issues.apache.org/jira/browse/VELOCITY-504 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 beta2 > Environment: Windows XP, Sun J2SE 1.5.0_09 >Reporter: Reggie Riser > Assigned To: Henning Schmiedehausen > Fix For: 1.5 > > Attachments: evaltooltest.patch, macrotest.zip > > > When upgrading from 1.5 beta 1 to beta2, I ran into a problem with one of our > macros that makes a call to Velocity.evaluate (via a tool) within a foreach > loop. With beta 1, everything worked fine. But we get a "cannot be > resolved" error with beta 2. The same code works fine outside of a macro > with either version. > I've distilled the issue we're having down to a simple test case and have > attached example code and a build file showing the problem. Just do an "ant > beta1" or "ant beta2" to see how the results differ between beta1 and beta2. -- 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: #evaluate
Good point. if we did this, keeping it simple (with the default
context) makes a lot of sense.
The #evaluate functionality seems simple enough, I'm enthused about
including it (eventually, anyway).
WILL
On 1/3/07, Nathan Bubna <[EMAIL PROTECTED]> wrote:
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]
--
Forio Business Simulations
Will Glass-Hu
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]
