call for vote soon on Texen/Anakia
Since Texen is now running successfully on Gump, I'm going to set up the binaries and call for a vote this weekend. Henning - you made some edits to the structure -- any last changes? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
texen gump run
Stepan, Thanks for fixing the Texen Gump build. Been meaning to tinker with the ant script-- did a commit tonight but it was unnecessary -- hadn't noticed you silently edited the Gump config a few days ago and the errors went away. Thinking about it, that's definitely the better approach so I reversed my patch (which might not have worked anyway). Appreciate the slient assistence. WILL -- Forwarded message -- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Apr 19, 2007 9:22 PM Subject: svn commit: r530635 - in /velocity/texen/trunk/build: build.xml testcases.xml To: [EMAIL PROTECTED] Author: wglass Date: Thu Apr 19 21:22:13 2007 New Revision: 530635 URL: http://svn.apache.org/viewvc?view=rev&rev=530635 Log: reversed previous change to Texen build. Apparently the Gump elves mysteriously made this work a few days ago by changing the Gump config. (Thanks Stepan!) Removed: velocity/texen/trunk/build/testcases.xml Modified: velocity/texen/trunk/build/build.xml Modified: velocity/texen/trunk/build/build.xml URL: http://svn.apache.org/viewvc/velocity/texen/trunk/build/build.xml?view=diff&rev=530635&r1=530634&r2=530635 == --- velocity/texen/trunk/build/build.xml (original) +++ velocity/texen/trunk/build/build.xml Thu Apr 19 21:22:13 2007 @@ -509,12 +509,70 @@ + depends="build-prepare,compile-test,test-texen,test-texen-classpath"/> - + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
Re: moving LogChutes from Tools to Engine
Well, there's two places, which should probably be merged. I like the way the first gives specific details. http://velocity.apache.org/engine/devel/build.html http://velocity.apache.org/engine/devel/jar-dependencies.html WILL On 4/19/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: On 4/2/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > I'm +1 on the CommonsLogLogChute in Engine. > > It probably also makes sense for ServetLogChute to be in Engine. I'm > not too worried about compile time dependencies as our build scripts > handles these automatically. Ok, i've been thinking about this more and talked myself into moving ServletLogChute into Engine for the sake of ultimately keeping useful LogChutes all in one place. Also, since the user must put the ServletContext into the runtime's application attributes for the ServletLogChute to function (and not merely have javax.servlet.ServletContext in the classpath), i'm thinking that this should probably precede JdkLogChute in the order for the default runtime.log.logsystem.class property. I'm going to go ahead and check this in. I just wanted to follow up on this thread to provide context and a good place for feedback (the critical kind is quite welcome :). > We should try to keep the list of dependencies up to date as that will > help people choose which jars to include/exclude when deploying. Agreed. Do we have a place where we do this? Can this be reflected in the POM? > WILL > > On 4/2/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Hey folks, > > > > So, the only reason CommonsLogLogSystem ever went into VelocityTools > > was that that was the path of least resistance for me at the time. I > > wanted it to be released soon, and Velocity releases didn't happen > > soon. > > > > Now that we are up to speed, more or less, the reality is that > > CommonsLogLogChute (LogSystem is deprecated) doesn't really fit in > > Tools as well as it fits in Engine. That's where the other LogChutes > > for major logging systems are, and that's where it should be. This is > > just a heads up that it is coming in shortly. > > > > The real question i have here is ServletLogChute (formerly known as > > ServletLogSystem). Again, we have adaptors for LogKit, Log4j, JDK > > Logging, Commons Logging (soon), and System.err/out. Does it make > > sense for Engine to provide a wrapper for servletContext.log() too? > > Our LogManager essentially chooses the appropriate LogChute from those > > configured to be allowed based on the environment of Velocity and the > > order of the configured LogChutes. It seems to me that it would make > > sense to have sending log output to the servlet's log as a higher > > priority than sending it to System.err/out, assuming that a > > ServletContext instance is available in the application attributes. > > > > On the flip side, we're trying to remove Servlet API dependencies from Engine... > > > > I could go either way. I'm just curious to hear other people's > > thoughts here. If no one cares, chances are that i will leave > > ServletLogChute in Tools for now. > > > > p.s. if anyone is wondering about LogChuteCommonsLog (aka > > LogSystemCommonsLog), i increasingly feel that it is anathema and will > > never escape Tools, even if it manages to survive there. :) > > > > - > > 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
Re: moving LogChutes from Tools to Engine
On 4/2/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: I'm +1 on the CommonsLogLogChute in Engine. It probably also makes sense for ServetLogChute to be in Engine. I'm not too worried about compile time dependencies as our build scripts handles these automatically. Ok, i've been thinking about this more and talked myself into moving ServletLogChute into Engine for the sake of ultimately keeping useful LogChutes all in one place. Also, since the user must put the ServletContext into the runtime's application attributes for the ServletLogChute to function (and not merely have javax.servlet.ServletContext in the classpath), i'm thinking that this should probably precede JdkLogChute in the order for the default runtime.log.logsystem.class property. I'm going to go ahead and check this in. I just wanted to follow up on this thread to provide context and a good place for feedback (the critical kind is quite welcome :). We should try to keep the list of dependencies up to date as that will help people choose which jars to include/exclude when deploying. Agreed. Do we have a place where we do this? Can this be reflected in the POM? WILL On 4/2/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Hey folks, > > So, the only reason CommonsLogLogSystem ever went into VelocityTools > was that that was the path of least resistance for me at the time. I > wanted it to be released soon, and Velocity releases didn't happen > soon. > > Now that we are up to speed, more or less, the reality is that > CommonsLogLogChute (LogSystem is deprecated) doesn't really fit in > Tools as well as it fits in Engine. That's where the other LogChutes > for major logging systems are, and that's where it should be. This is > just a heads up that it is coming in shortly. > > The real question i have here is ServletLogChute (formerly known as > ServletLogSystem). Again, we have adaptors for LogKit, Log4j, JDK > Logging, Commons Logging (soon), and System.err/out. Does it make > sense for Engine to provide a wrapper for servletContext.log() too? > Our LogManager essentially chooses the appropriate LogChute from those > configured to be allowed based on the environment of Velocity and the > order of the configured LogChutes. It seems to me that it would make > sense to have sending log output to the servlet's log as a higher > priority than sending it to System.err/out, assuming that a > ServletContext instance is available in the application attributes. > > On the flip side, we're trying to remove Servlet API dependencies from Engine... > > I could go either way. I'm just curious to hear other people's > thoughts here. If no one cares, chances are that i will leave > ServletLogChute in Tools for now. > > p.s. if anyone is wondering about LogChuteCommonsLog (aka > LogSystemCommonsLog), i increasingly feel that it is anathema and will > never escape Tools, even if it manages to survive there. :) > > - > 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: Changing Header.vm file on Locale change
On 4/17/07, santas <[EMAIL PROTECTED]> wrote:
Thanks for your reply
but i think i missed one point here that i am not using
velocity for my front end. I am using jsp with the portlets. And i think i
cant use this #parse( ) here in jsp.
correct.
I tryid solution but i don't know whether it is standard
or not.
What i tried to do is whenever i change "Locale" of my application it calls
on class,ok
now int hat class i added following code
VelocityEngine Velocity = new VelocityEngine();
Properties p = new Properties();
p.setProperty("file.resource.loader.path",
"C:\\Jetspeed-2.0\\webapps\\jetspeed\\decorations\\layout");
VelocityContext context= new VelocityContext();
context.put("langname",strLanguage);
Velocity.init(p);
Template temp = Velocity.getTemplate("tempheader.vm");
StringWriter writer = new StringWriter();
temp.merge(context,writer);
byte[] test= writer.toString().getBytes();
FileOutputStream out = new
FileOutputStream("C:\\Jetspeed-2.0\\webapps\\jetspeed\\decorations\\layout\\header.vm");
out.write(test);
out.close();
now i had written on file called "tempheader.vm"
#set ($MESSAGES =
$portletConfig.getResourceBundle($renderRequest.Locale))
#includeJavaScriptForHead()
#IncludeStylesheets()
#if($langname== "it")
italian meta
data here
#else
english meta
data here
#end
now whatever output i get by using this tempheader.vm template i write it to
another template that is "header.vm"
now it is working fine now but i dont know wether it is standard approch or
not.
neither do i. ask the Jetspeed list if you are concerned about it.
i trying to seach about how this jetspeed container manages file writing for
large no of request.(how it synchronizes all request that write single file
)
Please can you put some light on this
nope, i don't use Jetspeed. you would have better luck asking on
their user mailing list, rather than asking on the Velocity list.
Thanks
Nathan Bubna wrote:
>
> This looks like it might be a good situation to use the
> "MultiViewsTool" to find the appropriate header.vm file:
>
>
http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/view/i18n/MultiViewsTool.html
>
> I haven't used it myself, but my understanding is that you use it to
> find the appropriate template name for a specified locale (or the
> default locale if there is none for the specified locale). And then
> you use the #parse() or #include() directives to load that
> template/file.
>
> So, assuming that you are using VelocityTools and the MultiViewsTool
> is in the context as $i18n, you would probably do something like:
>
> #parse( $i18n.findLocalizedResource("header.vm", $request.locale) )
>
>
> of course, i don't know if you are using VelocityTools or the
> VelocityViewServlet. You mentioned portlets. Are you using a
> specific portlet framework? You might consider asking them for advice
> on this too. It could be challenging to set up VelocityTools with
> that framework; i'm not really sure how that would work...
>
> On 4/16/07, santas <[EMAIL PROTECTED]> wrote:
>>
>> Hi
>> What i want to do is that whenever i change "Locale " of my
>> application
>> depending on that locale i want to change my
>> "header.vm" files contetnt for Meta tag.
>>
>> On my first page i am having one link that will chage my "Locale " of
>> application now suppose i click on link and now new Locale is "en" then
>> i
>> want tag for en to be used by browser.
>>
>> Whenever i change my Locale one portlet is called and that calls
>> another
>> class to set this locale in session for that user. I tryid to put that in
>> Velocity context but
>>
>> Now i am very much new to this velocity and trying lot many things but
>> getting nothing.
>> And my big confusion is that is this "header.vm" is called before that
>> portlet is called.
>> Can anybody give me proper direction please.
>>
>>
>> Thanks
>>
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/Changing-Header.vm-file-on-Locale-change-tf3589047.html#a10029907
>> Sent from the Velocity - Dev mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscri
[jira] Commented: (VELOCITY-528) Velocity 1.5 raises errors for templates that ran in 1.4.
[
https://issues.apache.org/jira/browse/VELOCITY-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490109
]
Nathan Bubna commented on VELOCITY-528:
---
Documentation of this regression has been added to the
http://wiki.apache.org/velocity/Velocity15ReleaseNotes
It should also be added to any/all 1.5.x release notes before marking this
issue resolved.
> Velocity 1.5 raises errors for templates that ran in 1.4.
> -
>
> Key: VELOCITY-528
> URL: https://issues.apache.org/jira/browse/VELOCITY-528
> Project: Velocity
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.5
> Environment: Windows XP SP2, JDK 1.5
>Reporter: Michael Giroux
> Fix For: 1.5.1, 1.6
>
>
> Migrated from Velocity 1.4 to 1.5. I have several templates that ran in 1.4
> and now fail in 1.5. I raised this in the mailing list and Nathan Bubna
> asked me to file a bug.
> This is probably an error in my template, but 1.4 allowed it to execute
> without complaints. I might have been lucky that nothing bad happened.
> Existing templates contain the following.
> public $method.returnType $method.name(
> #foreach($param in $parameters)
> ...
> #end
> The intent here is to emit a java method signature for a method named
> $method.name . This works in 1.4.
> In Velocity 1.5, an error is thrown indicating that the #foreach is
> unexpected. Velocity 1.5 is expecting a method parameter becuase the
> variable name is terminated by an open paren.
> I fixed the problem by adding curly braces to the template as follows:
> public $method.returnType ${method.name}(
> #foreach($param in $parameters)
> ...
> #end
> This is probably a bug in 1.4, and poor coding practice in my template, but
> given the fact that it did work and now doesn't, there should be some mention
> of this "improvement" in the 1.5 release notes.
--
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]
[Velocity Wiki] Update of "Velocity15ReleaseNotes" by NathanBubna
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Velocity Wiki" for
change notification.
The following page has been changed by NathanBubna:
http://wiki.apache.org/velocity/Velocity15ReleaseNotes
The comment on the change is:
Add note about fix for Velocity-528 regression
--
* In order to run "ant test" with ant 1.6.x, you will need to copy the
junit.jar into /lib. Otherwise, please upgrade to ant 1.7 (which
accesses the junit jar from within the Velocity classpath).
* Macros cannot be defined in one file and included with #parse in another.
See MacroIssues for more information.
* If you call VelocityEngine.evaluate() (or use the RenderTool) from within
a macro and a #foreach loop, you will not be able to access the loop variable.
See [https://issues.apache.org/jira/browse/VELOCITY-504 Velocity-285].
- * If your references used shorthand notation (e.g. "$foo") and were followed
immediately by a "(" character, they may have slipped through a whole in the
parser which was closed in Velocity 1.5, causing them to throw parse
exceptions. See [http://issues.apache.org/jira/browse/VELOCITY-528
Velocity-528].
+ * If your references used shorthand notation (e.g. "$foo") and were followed
immediately by a "(" character, they may have slipped through a whole in the
parser which was closed in Velocity 1.5, causing them to throw parse
exceptions. See [http://issues.apache.org/jira/browse/VELOCITY-528
Velocity-528]. Using formal notation (e.g. "${foo}") will resolve this.
* There remain various subtle escaping bugs
=== Other Notes ===
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Velocity Wiki] Update of "Velocity15ReleaseNotes" by NathanBubna
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Velocity Wiki" for
change notification.
The following page has been changed by NathanBubna:
http://wiki.apache.org/velocity/Velocity15ReleaseNotes
The comment on the change is:
Add note for Velocity-528
--
* In order to run "ant test" with ant 1.6.x, you will need to copy the
junit.jar into /lib. Otherwise, please upgrade to ant 1.7 (which
accesses the junit jar from within the Velocity classpath).
* Macros cannot be defined in one file and included with #parse in another.
See MacroIssues for more information.
* If you call VelocityEngine.evaluate() (or use the RenderTool) from within
a macro and a #foreach loop, you will not be able to access the loop variable.
See [https://issues.apache.org/jira/browse/VELOCITY-504 Velocity-285].
+ * If your references used shorthand notation (e.g. "$foo") and were followed
immediately by a "(" character, they may have slipped through a whole in the
parser which was closed in Velocity 1.5, causing them to throw parse
exceptions. See [http://issues.apache.org/jira/browse/VELOCITY-528
Velocity-528].
* There remain various subtle escaping bugs
=== Other Notes ===
-
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/
