Re: Board report for Wednesday morning
Sure. let's see... Velocity Tools is working through a short backlog of patch contributions and bugs hoping to get a 1.3 version released before Velocity 1.5 goes final. It's also the plan to test VelocityStruts 1.3 against Struts 1.3 for compatibility. VelocityTools 1.3 is likely to be the last major release in the 1.x line, as i've already started planning for version 2. On 11/11/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] writes: I'll take care of Velocity. Nathan, can you write me a few lines for Velocity Tools? Thanks. Best regards Henning VELOCITY-470 reminded me that you've not been added to committee-info.txt, which means you've not been nudged for a board report for Wednesday. If you can send one in it would be great. Basically a status of how the move is going and any current development activity (1.5 right?). You'll need to report monthly for the next 3 months, settling into a Feb, May, Aug, Nov cycle after that. Hen - 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 commands, e-mail: [EMAIL PROTECTED]
Re: is Texen orphaned?
On 11/25/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Apparently, the main example in the Texen docs in Velocity 1.4 is broken. Geir broke it in early 2002, and Shinobu found and fixed the problem in early 2005. So while this has been fixed for 1.5, for the past couple of years the docs for the released version 1.4 have been wrong and no one has complained. http://issues.apache.org/bugzilla/show_bug.cgi?id=5183 http://issues.apache.org/bugzilla/show_bug.cgi?id=33206 http://jakarta.apache.org/velocity/docs/texen.html Also, there don't seem to be any experienced users on the mailing list. When a user recently asked about this no one responded until I had a chance to look into it. (I try to be responder-of-last-resort for these type of things). My point... Texen seems like an orphaned project. I'm guessing there's a few embedded users (Torque) so we shouldn't drop it. But I'd like to move it (after 1.5) to a separate subproject. Probably Anakia too. Comments? +1 They definitely need to be extricated from the core and moved to their own projects. WILL -- 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: svn commit: r480868 -
In 1.3, i've been on something of a push to simplify the syntax and readability of how tools are used in templates. The idea is to make an elegant, simple VTL interface for these tools, even if it looks odd from a java perspective. Given the choice between: $context.context and $context.this i consider the latter to be the most elegant and self-explanatory. On 11/30/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: +public ViewContext getThis() getThis? Do we already have a getContext()? 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]
Re: svn commit: r480849 -
technically, it would be an empty map not empty list, but even so, i'm
not sure about this. if we can say for sure that no one (especially
us) will ever want to tell the difference between an empty toolbox and
no toolbox being set, then it would be marginally simpler to ensure
that toolbox is never null.
at this point, it's not a great burden to always test for the
toolbox's presence and potentially provides more a more useful
interface.
in other words, i'll think about this...
On 11/30/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
+public Map getToolbox()
+{
+if (this.toolbox != null)
+{
+return Collections.unmodifiableMap(this.toolbox);
+}
Wouldn't it be better (and probably remove a lot of these tests) to make sure
that the toolbox can never be null (but contains an empty List?).
+return null;
}
I'd prefer Collections.EMPTY_LIST. Removes the necessity of always
checking for null.
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]
Veltools 1.3 - Showcase Example
hey folks, you probably noticed that i just checked in a new example app for VelocityTools to replace the layout example. this is something i've been thinking of doing for years, and finally got around to doing. basically, it provides demonstrations (most of which are interactive) of all the Generic and VelocityView tools we have. there is certainly plenty of room for improvement in the usefulness of the examples, but i figured it was time to get it out and see what ya'll think. if some of you were willing to check it out and give it a test run, i'd love to get some feedback. It's easy: - check out the latest revision of VelocityTools from svn - run 'ant showcase' - follow the instructions printed out at the end thanks! p.s. VelocityView and the Generic Tools are largely ready for a 1.3 release. if anyone wants to help me get 1.3 out the door, i'd love some help updating the VelocityStruts dependencies and making sure VelocityStruts is fully compatible with the Struts 1.3.x series. (Marino?) Please note that with Tiles going independent as a TLP and Struts 2.x soon on the way, the future of VelocityStruts beyond VelocityTools 1.3 is very much in question. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Veltools 1.3 - Showcase Example
On 12/11/06, Claude Brisson [EMAIL PROTECTED] wrote: Le lundi 11 décembre 2006 à 09:45 -0800, Nathan Bubna a écrit : On 12/9/06, Claude Brisson [EMAIL PROTECTED] wrote: Looks very cool. That's a lot of work! Some remarks: - Alternator: we'd like the hand-made examples to return several values... not that important. not sure i understand... Just that when I give the alternator ['blue','red'], I'd like to see blue, red, blue rather than just blue (that is, it should be evaluated several times). Really not that important. nah. i'd like to keep the function demos realistic. things like that can go in a full demo at the bottom, such as the ones that IteratorTool or SearchTool have. i've actually been adding a few more of these and will check them in shortly. - Date $date.getDay([ ]) $date.getMont([ ]) $date.getYear([ ]) those three methods take a Date argument, so the text field doesn't help much... in fact we should also have string versions for those three methods (that rely on toDate()). actually, those three methods take an Object argument which is automatically fed through toCalendar(Object) which eventually delegates to toDate(Object) whose last resort is parsing the String value of the Object. So, they can be used as is. However, i agree that they're not especially useful like this. i'll drop the quotes around the DateTool function examples. Ok, I browsed the sources too fast. But I did so after having tried 3 or 4 different syntaxes in the field getDay([]), which every newcomer will do as well... This time I tracked the trail to its very end and saw that the default behaviour is to fetch a date time medium format, which means the only string that works is Dec 11, 2006 9:07:05 PM, wich is ok as a default formatting string but not so smart when it comes to parsing... We should include some guessing algorithm, and I'm sure we can easily find a pretty one around there in the apache codebase just waiting for us. that would be cool. the string - date parsing of DateTool.toDate(Object) is simplistic at best by default. if you use the same format for output and input, then you can configure DateTool to use that as the default. otherwise, you should use DateTool.toDate(String format, Object date) or one of the other toDate() methods. so basically, there's plenty of capability in DateTool, but only limited magic. improvements are welcome! - Cookie $cookie.all should be displayed with a #foreach, so that we actually see the cookies. Minor. can do. The CSS layout rocks! Maybe we can use it by default. i guess we could. hadn't really thought about it. Last but not least, this webapp could serve as a basis for testcases. Talking about this, I built a testcase for Velosurf (both whitebox and blackbox using Jetty), so maybe I can work on this for the Tools. interesting idea. would this be automated or automate-able? Could not be more automated. Downloads needed jars, starts Jetty, submits forms, compares results, stops Jetty. And what is cool is that you can manually launch the ant target start-jetty and point your browser to -let's say, localhost:8081, when you need to debug the testcases themselves. It uses HttpUnit to do so. The HttpUnit licence is not an ASF one, but is clearly compatible (never seen a shorter licence: http://httpunit.sourceforge.net/doc/license.html ) and already used by several apache projects. sounds awesome! i'd definitely be interested in exploring such things. Claude Claude Le vendredi 08 décembre 2006 à 12:02 -0800, Nathan Bubna a écrit : hey folks, you probably noticed that i just checked in a new example app for VelocityTools to replace the layout example. this is something i've been thinking of doing for years, and finally got around to doing. basically, it provides demonstrations (most of which are interactive) of all the Generic and VelocityView tools we have. there is certainly plenty of room for improvement in the usefulness of the examples, but i figured it was time to get it out and see what ya'll think. if some of you were willing to check it out and give it a test run, i'd love to get some feedback. It's easy: - check out the latest revision of VelocityTools from svn - run 'ant showcase' - follow the instructions printed out at the end thanks! p.s. VelocityView and the Generic Tools are largely ready for a 1.3 release. if anyone wants to help me get 1.3 out the door, i'd love some help updating the VelocityStruts dependencies and making sure VelocityStruts is fully compatible with the Struts 1.3.x series. (Marino?) Please note that with Tiles going independent as a TLP and Struts 2.x soon on the way, the future of VelocityStruts beyond VelocityTools 1.3 is very much in question
Re: Veltools 1.3 - Showcase Example
On 12/10/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Claude Brisson [EMAIL PROTECTED] writes: p.s. VelocityView and the Generic Tools are largely ready for a 1.3 release. if anyone wants to help me get 1.3 out the door, i'd love some help updating the VelocityStruts dependencies and making sure VelocityStruts is fully compatible with the Struts 1.3.x series. I pimped up the velocity gump build a bit; if it passes the next cycle then I will switch from the packaged struts to struts-action, struts-taglib, struts-tiles dependency; if that passes that should be a good sign that vel-tools works with struts 1.3. thanks! that'll be very helpful. How about releasing a beta to get people ready for this? first i want to upgrade the struts dependencies. right now the build still uses the 1.2.x series. then we'll push a beta out. 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]
Re: Veltools 1.3 - Showcase Example
I've debated that myself a dozen times. The main issue is that i've not had cause to use that particular function myself. I just added the getMonth() and getDay() methods as logical fellows of the getYear() method that i really wanted. I could easily be swayed either direction, and either way, the documentation definitely should be improved. Anyone else have thoughts on this one? I'm actually leaning back toward the normal 1-based month and away from the j.u.Calendar's 0-based month right now. While the DateTool is in the generic package, it's primary use is probably in a view layer of an application, where it is more natural to present the human month value rather than the machine one. On 12/11/06, Claude Brisson [EMAIL PROTECTED] wrote: Le lundi 11 décembre 2006 à 12:47 -0800, Nathan Bubna a écrit : so basically, there's plenty of capability in DateTool, but only limited magic. improvements are welcome! Ah, one last thing (for now) about the DateTool that I forgot to mention: are we sure we want to keep the jdk zero-based behaviour for the month? If so we should recall that in the docs, rather twice than once... Claude - Cookie $cookie.all should be displayed with a #foreach, so that we actually see the cookies. Minor. can do. The CSS layout rocks! Maybe we can use it by default. i guess we could. hadn't really thought about it. Last but not least, this webapp could serve as a basis for testcases. Talking about this, I built a testcase for Velosurf (both whitebox and blackbox using Jetty), so maybe I can work on this for the Tools. interesting idea. would this be automated or automate-able? Could not be more automated. Downloads needed jars, starts Jetty, submits forms, compares results, stops Jetty. And what is cool is that you can manually launch the ant target start-jetty and point your browser to -let's say, localhost:8081, when you need to debug the testcases themselves. It uses HttpUnit to do so. The HttpUnit licence is not an ASF one, but is clearly compatible (never seen a shorter licence: http://httpunit.sourceforge.net/doc/license.html ) and already used by several apache projects. sounds awesome! i'd definitely be interested in exploring such things. Claude Claude Le vendredi 08 décembre 2006 à 12:02 -0800, Nathan Bubna a écrit : hey folks, you probably noticed that i just checked in a new example app for VelocityTools to replace the layout example. this is something i've been thinking of doing for years, and finally got around to doing. basically, it provides demonstrations (most of which are interactive) of all the Generic and VelocityView tools we have. there is certainly plenty of room for improvement in the usefulness of the examples, but i figured it was time to get it out and see what ya'll think. if some of you were willing to check it out and give it a test run, i'd love to get some feedback. It's easy: - check out the latest revision of VelocityTools from svn - run 'ant showcase' - follow the instructions printed out at the end thanks! p.s. VelocityView and the Generic Tools are largely ready for a 1.3 release. if anyone wants to help me get 1.3 out the door, i'd love some help updating the VelocityStruts dependencies and making sure VelocityStruts is fully compatible with the Struts 1.3.x series. (Marino?) Please note that with Tiles going independent as a TLP and Struts 2.x soon on the way, the future of VelocityStruts beyond VelocityTools 1.3 is very much in question. - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Veltools 1.3 - Showcase Example
Ok. Make sure you move it to the Struts 1.x head, and not Struts 2.x. They are entirely different frameworks. On 12/11/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: velocity-tools builds again (see http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/index.html), I will move it to the struts HEAD today; let's see how it works out. :-) Best regards Hennig On 12/10/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Claude Brisson [EMAIL PROTECTED] writes: p.s. VelocityView and the Generic Tools are largely ready for a 1.3 release. if anyone wants to help me get 1.3 out the door, i'd love some help updating the VelocityStruts dependencies and making sure VelocityStruts is fully compatible with the Struts 1.3.x series. I pimped up the velocity gump build a bit; if it passes the next cycle then I will switch from the packaged struts to struts-action, struts-taglib, struts-tiles dependency; if that passes that should be a good sign that vel-tools works with struts 1.3. thanks! that'll be very helpful. How about releasing a beta to get people ready for this? first i want to upgrade the struts dependencies. right now the build still uses the 1.2.x series. then we'll push a beta out. 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 commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Site - Preview
I like the direction this is heading, especially as laid out here: http://wiki.apache.org/jakarta-velocity/VelocitySite I'll help with the Tools docs at least. But it might be a week or so. I've gotta get some other work done first. On 12/11/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [Hm. I could have sworn I've sent this out already. Seems it never made it] To let you know what I've been busy over the weekend: I've been wrestling with maven 2 and site building. A preview of where I intent to go is currently visible at http://velocity.apache.org/staging/ Comments, Criticism, Help, Patches wanted. Most of that is already in the site svn; I've created a custom skin for the site, that is not yet there. 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]
Re: Velocity ImportTool Question
On 12/14/06, Claude Brisson [EMAIL PROTECTED] wrote: (really moving it to the dev list...) Yeah, ever since Tomcat 5.5 made the obnoxious decision to use commons-logging (which i could have sworn was supposed to be just a log wrapper/adapter) as a full-on logging solution responsible for generating servlet log files and printing to them, our former method of handling things (pointing all commons-logging messages to Velocity's LogSystem and pointing Velocity's LogSystem at the provided servlet log) fails with an infinite loop. Yes, I remember that. It's been a while since i was fully familiar with the nuances of this issue, but i believe things are currently as follows: Velocity's LogSystem is being pointed at the servlet log, and all VelocityTools messages are being sent to commons-logging. If you are using Tomcat 5.5.x, then this works fine as the VelocityTools and Velocity methods both end up in the servlet log. If you are using an older Tomcat or a different servlet container, then you will not get VelocityTools messages in your servlet log without actively configuring commons-logging to print to Velocity's LogSystem (see the LogSystemCommonsLog class for details). Once Velocity 1.5 is released, it is my intent to push forward with work on VelocityTools 2.x and leave the VelocityTools 1.x series behind. VelocityTools 2.x will require Velocity 1.5+ as a dependency (among other major changes). Among the benefits of this will be the ability to drop commons-logging from VelocityTools and use the new and improved LogChute support in Velocity 1.5+. This will once more allow us to funnel all Velocity and VelocityTools messages to the same place, regardless of which servlet container you are using. Yes, but my concern was that ToolboxManagers and logging tools directly uses import org.apache.commons.logging.Log via LogFactory.getLog(ServletToolboxManager.class) and not via LogSystemCommonsLog. No, the way we are using commons-logging is the appropriate way. The whole idea of it is/was that you use the LogFactory and Log interfaces so that you can easily swap out implementations of Log (like the LogSystemCommonsLog). You are not supposed to use the implementations directly. If you do, then you might as well do what i plan to do in 2.x and ditch commons-logging altogether. So without Tomcat 5.5.x and any proper commons-loggin configuration, you'll see the VVS logs allright (letting you think that tools logging is ok) but no error message from the servlet toolbox manager. No, what you are seeing in such a case is just *Velocity* log messages. The VelocityViewServlet does precious little logging of its own, pretty much only in cases of major initialization errors. Of course, it does log directly to the servlet log. This is because in such cases it may be that Velocity failed to init and we can't log there. I'm not enough familiar with this problem and with commons-logging to know which solution would be best : - implement a LogFactory ? - create setLog(Log) methods (introspected for tools the same way as init and configure) ? No, this is not the way to use commons-logging. Here are the options: a) Improve documentation to make it clear that those not using Tomcat 5.5+ must add a commons-logging.properties file to the root of the classpath that contains the following line: org.apache.commons.logging.Log=org.apache.velocity.tools.log.LogSystemCommonsLog or b) by default, point all commons-logging messages to LogSystemCommonsLog (as i believe we used to do), but stop having Velocity's LogSystem use the ServletLogger by default. this will mean that all log output for Velocity and VelocityTools will follow Velocity's default logging configuration (unless users change that via velocity.properties). but I definitely think we should do sthing about this for the 1.3 release. The options above are our only options for improving the situation in 1.3. Claude In short, the Tomcat people did what Geir could not and successfully convinced me that it is a very bad idea to use commons-logging in a webapp framework. Claude Le jeudi 14 décembre 2006 à 12:30 -0800, Nathan Bubna a écrit : On 12/14/06, Tod Thomas [EMAIL PROTECTED] wrote: Nathan Bubna wrote: and what does your web.xml have? Sorry, plain vanilla: !-- Define Velocity template compiler -- servlet servlet-namevelocity/servlet-name servlet-class org.apache.velocity.tools.view.servlet.VelocityViewServlet /servlet-class init-param param-nameorg.apache.velocity.toolbox/param-name param-value/WEB-INF/toolbox.xml/param-value /init-param init-param param-nameorg.apache.velocity.properties/param-name param-value/WEB-INF/velocity.properties/param-value /init-param load-on-startup10/load-on-startup /servlet !-- Map *.vm
Re: Velocity Site - Preview
First, general thoughts I would like to see our web site reflect our charter in the sense that the Velocity Engine is always prominent and pre-eminent. It is a requirement that the other subprojects be dependent on that core center pole, otherwise the umbrella will become a mere sack. I'm not sure how best to represent this on our front page, but i think it is important that that be the case. Apart from this emphasis, i generally agree with Henning's thoughts on the front page. Regarding Velocity in a webapp... I like having a front page link to this guide. Like Will, it feels like there have been fewer simplistic questions on this since we added that page. I also think it would be good to have a link right above or below it that quickly tells how to use Velocity outside a webapp. The title of this would probably depend on the examples created for it. Which, by the way, i'm not sure we have any good, simple, easy-to-get-started-with, examples of this. Maybe i'll take a shot at that before 1.5 goes final... On 12/18/06, Claude Brisson [EMAIL PROTECTED] wrote: Some remarks / suggestions... Le dimanche 17 décembre 2006 à 14:10 +0100, Henning Schmiedehausen a écrit : New users need to know -- What the heck is Velocity? +1. So what is it? Is it a templating engine? A toolbox for a templating engine? What is the Velocity project. I'm struggling with that answer myself. ;-) Apache Velocity is the Velocity template engine and a set of complementary and closely-tied projects. Also (more pragmatic... ahum... not purely aesthetic) the project (in the title) vs projects (in the menu) - what about changing the title to sthing like the Velocity Umbrella or the Velocity Connection? i think we should generally refer to the Apache Velocity TLP as Apache Velocity and put no further nouns into it. If we need a generic noun as a synonym, i'd stick with project as that is how the ASF views us collectively. -- What's the latest version? +1. Latest Version of what? We already have three sub projects. What about including validation/compatibility/voting steps for subprojects, so that a particular version of a subproject is officially linked with every engine release? Hence, there would be a Velocity package version, the same as the core, and newcomers can avoid dealing with subproject versions. Advanced users who want to mix versions can fetch infos on subprojects pages and use subversion. I think this is a great idea. Not a high priority, but definitely something i'd like to work on once we get the TLP move completed and Velocity Engine 1.5 and VelocityTools 1.3 out the door. At this point, all VelocityTools releases are compatible with Velocity Engine 1.3+. Starting with VelocityTools 2.x, we'll probably require Velocity Engine 1.5+. It would be fantastic to have some simple way of expressing on overview of all these dependencies on our web site, especially as we bring in other subprojects and push Anakia and Texen out of the Engine. Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.3-beta1
On 12/18/06, Claude Brisson [EMAIL PROTECTED] wrote: +1, with the only exception that we should add to the docs the mention you suggested about the commons-logging.properties file (btw, thanks for clarifying the situation for me!) - this was your a) proposal. sure. just gotta figure out where best to do that now... Claude Le lundi 18 décembre 2006 à 12:06 -0800, Nathan Bubna a écrit : 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: [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.3-beta1
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]
Re: docs / javadocs in the tools svn?
The reasons for this are primarily historical at this point. I believe the original motivation was to make it easy to update the public site by just doing svn update. At this point, i guess i'm +0.1 on removing the generated documentation from version control in this version. Once we have velocity.apache.org up and a totally different way of building the site, then i'll be +1. On 12/22/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Hi, I noticed that the Javadocs and docs output are checked into SVN. Besides from giving me a big number of M(odified) files from SVN when I do svn status after building the tools, do we need that? We do build these files with a regular build anyway and people actually getting the source code from SVN probably know their way around enough to build these themselves. I'm +1 for removing the generated files from SVN. 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]
Re: [jira] Commented: (VELOCITY-502) Skip jar verification unless force.jar.loading is true
On 12/23/06, Claude Brisson [EMAIL PROTECTED] wrote: Le samedi 23 décembre 2006 à 15:45 -0800, Nathan Bubna (JIRA) a écrit : I don't really care. Both have advantages, both will work fine. If you're going to do the work, i say you should get to decide. :) That's the new commiter syndrom... feeling like having to ask before doing nasty things inside the sourcetree... it will pass... ;-) :) well, in your defense, it is polite to give a heads up before acting on something that was being debated. of course, for me there's few arguments stronger than action, especially when it comes to something inconsequential like this. Claude Skip jar verification unless force.jar.loading is true Key: VELOCITY-502 URL: http://issues.apache.org/jira/browse/VELOCITY-502 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 1.5 beta2 Environment: all Reporter: Claude Brisson Priority: Minor Fix For: 1.5 Attachments: jar-downloading.patch When the www.iblibo.org/maven repository is down (as it seems right now, at least from here), or when you want to work form an unconnected place (yes, it still exists...), build fails because ant wants to check every jar timestamp. The attached patch modifies this behaviour: if a jar file is already present, the repository is not hit at all (why would we have to check any timestamp anyway since version numbers are present inside filenames?!). The new force.jar.loading property forces reloading of jar files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release VelocityTools 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]
Re: JIRA issues - resolve or close
I can see some value in this process, but not enough that i really care either way for myself. I'll do whatever pleases. :) On 1/11/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Hi, I just reopened and resolved some issues. Reason for this is: I'd like to follow the proposed status lifecycle as shown on http://www.atlassian.com/software/jira/docs/v3.7.1/issues.html#StatusTypes. That means, we don't close issues immediately but resolve them with a resolution (Fixed/Won't fix/Later/Can't reproduce etc.). Once we to a particular release, we then close all issues that have been marked resolved for that release. Reason for this is to distinguish between issues for the current release and historic ones. It might be that this is too artificial / I am too anal here. If you think so, please speak up. ;-) 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]
Re: Tiles mailing list Was: Re: [jira] Commented: (VELTOOLS-64) Geronimo 1.1.1 with Tomcat install fails to render links correctly
Ah... far in time. I was thinking space. :) Yeah, the lists are all
up. Come join the fun!
On 1/16/07, Claude Brisson [EMAIL PROTECTED] wrote:
That's not odd at all, last time I tried the mailing list wasn't yet up,
just asking how far in time, irrelevant of course if it is open, c u
there :-)
Claude
Le mardi 16 janvier 2007 à 13:37 -0800, Nathan Bubna a écrit :
That's an odd question. Not sure what far means when we're talking
about mailing lists, but i am subscribed to all the newly created
Tiles TLP mailing lists.
On 1/16/07, Claude Brisson [EMAIL PROTECTED] wrote:
Just a small question out of topic : Nathan, are you far from a specific
tiles mailing list?
c
Le mardi 16 janvier 2007 à 08:51 -0800, John Eichelsdorfer (JIRA) a
écrit :
[
https://issues.apache.org/jira/browse/VELTOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465209
]
John Eichelsdorfer commented on VELTOOLS-64:
I think I mentioned the exact versions of things except for Struts and
Tiles. My struts is not a latest, but I don't remember the exact version here.
The thing is, I took the same exact war for http://www.jobbank.com that
works on straight Tomcat 5.5 and placed it in Geronimo 1.1.1. It worked perfectly in
the one and failed as shown in the other in only that way. You can see this working in
production if you go to the site.
As I am not in front of that code at the moment I can't look into it
right now, but I will try to give more particulars tonight or tomorrow including a
bigger code snippet. The partial code above is correct though as I cut and pasted it.
Geronimo 1.1.1 with Tomcat install fails to render links correctly
--
Key: VELTOOLS-64
URL: https://issues.apache.org/jira/browse/VELTOOLS-64
Project: Velocity Tools
Issue Type: Bug
Components: VelocityStruts
Affects Versions: 1.2
Reporter: John Eichelsdorfer
Priority: Critical
Fix For: 1.3
I have been using VelocityTools for years and have a project
successfully running in production on standalone Tomcat 5.5. When I run the same war file
on Geronimo 1.1.1, links do not render correctly. Geronimo also uses a 5.5 version of
Tomcat in the standard distribution I am using.
I am using Velocity 1.5 beta 1 and VelocityTools 1.2 from Maven.
Given the following code that is parsed into a main file:
a
href=$link.setAction('/pub/jobpost/list/submit').addQueryData(c,$!countrySel).addQueryData(r,$!pop.popId)$!pop.popName
Jobs/a
On Tomcat 5.5 standalone get:
http://www.jobbank.com/action/pub/jobpost/list/submit?c=USr=CA
On Geronimo 1.1.1 with the same war file, we get:
http://action/pub/jobpost/list/submit?c=USr=CA
The only difference obviously is the lack of domain name. Other links
seem to work correctly that are referenced with an absolute path. For example:
a href=/action/exec/resume/choice/setup title=Click here
shows the correct hostname in the front.
I was using a non-beta velocity, but moved up to using the beta to rule out this
being the issue. I also did a search on the Geronimo distribution for any other file matching
velocity but came up empty.
I am not in a rush for this fix, but I think it is important to know
that it will work in a next 1.5 Velocity release else people will be constantly using
snapshots rather then a steady 1.5 build if this is where the problem lies.
I am hoping it is somehow just a configuration issue, though I am using
the most basic Geronimo setup.
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[veltools] 1.3 freeze soon...
Just giving fair warning to anyone planning/hoping to make any further changes to VelocityTools before 1.3 is released... My current plan is to call for a vote to release 1.3-rc1 on Monday. At that time, it would be rather unhelpful for further changes to be made, since that would require a re-vote and/or a second RC release. So, if you want to make changes, please make them soon or at least wait until the vote finishes and i create a 1.3-rc1 tag. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project velocity-tools (in module velocity-tools) failed
VelocityTools is getting a Gump failure because we recently upgraded our Validator tool to use the org.struts.validator.Resources.getVarValue(Var,ServletContext,HttpServletRequest,boolean) method (to mirror the same change in JavascriptValidatorTag). The problem appears to be that the packaged-struts project in Gump (which we've been listing as a dependency) is an out of date JAR, and the struts project is a no-op. Is anyone in the Struts1 camp interested/able/willing to update Struts' presence in Gump? If not, i may try to take a stab at it, but it's been ages since i tried to build Struts myself, much less tell Gump how to do it. On 1/19/07, Velocity Gump dev@velocity.apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project velocity-tools has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - velocity-tools : VelocityTools project Full details are available at: http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-beanutils exists, no need to add for property commons-beanutils.jar. -DEBUG- Dependency on commons-collections exists, no need to add for property commons-collections.jar. -DEBUG- Dependency on commons-digester exists, no need to add for property commons-digester.jar. -DEBUG- Dependency on commons-lang exists, no need to add for property commons-lang.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging.jar. -DEBUG- Dependency on commons-validator exists, no need to add for property commons-validator.jar. -DEBUG- Dependency on jakarta-oro exists, no need to add for property oro.jar. -DEBUG- Dependency on velocity-engine exists, no need to add for property velocity.jar. -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property servlet.jar. -DEBUG- Dependency on struts-sslext exists, no need to add for property sslext.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-core.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-taglib.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-tiles.jar. -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/gump_work/build_velocity-tools_velocity-tools.html Work Name: build_velocity-tools_velocity-tools (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar -Doro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-19012007.jar -Dstruts-core.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dvelocity.jar=/usr/local/gump/public/workspace/velocity-engine/bin/velocity-19012007.jar -Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-19012007.jar -Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar -Dskip.jar.loading=true -Dsslext.jar=/usr/local/gump/public/workspace/struts-sslext/web/WEB-INF/lib/sslext.jar -Dstruts-tiles.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/commons-lang-19012007.jar -Dproject.version=19012007 -Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator-19012007.jar -Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-19012007.jar -Dstruts-taglib.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-19012007.jar -Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar all [Working Directory: /usr/local/gump/public/workspace/velocity-tools] CLASSPATH:
Re: [RESULT] [VOTE] Release VelocityTools 1.3-beta1
Sorry, wrong thread. let's try that again... On 1/25/07, Nathan Bubna [EMAIL PROTECTED] wrote: The vote has passed! I'll tag the release today and try to upload it tonight or tomorrow. Announcement should follow once the release is mirrored. PMC +1 Nathan Bubna Will Glass-Husain Henning Schmiedehausen Committer +1 Claude Brisson User/Contributor +1 Malcolm Edgar On 12/18/06, Nathan Bubna [EMAIL PROTECTED] wrote: 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: [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release dist directory structure
Ok, i've reorganized the releases in our dist directory. The sync'ing
between people.apache.org and www.apache.org has already partly
updated things at http://www.apache.org/dist/velocity/, the rest
should happen within the next 24 hours.
Henning, i've updated all the relevant stuff in velocity/site that i
can think of, but i have not been able to successfully build it
locally, much less deploy it. Would you mind deploying the updates
for me today or tomorrow? Or, if you want to help me figure it out,
here's the error i'm stuck on:
[INFO] Building Apache Velocity Site
[INFO]task-segment: [post-site]
[INFO]
[INFO] [velocity-site-doxia-renderer:pre-site {execution: default}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.velocity.site:velocity-site-news-plugin:1.1.0:pre-site':
Un
able to find the mojo
'org.apache.velocity.site:velocity-site-news-plugin:1.1.0:pre-site' in
the plugin 'org.apache.velocity.site:
velocity-site-news-plugin'
This is when running mvn in site/site after successfully running
mvn in site/tools. And i'm using Maven 2.0.4 with
maven-site-plugin 2.0-beta-5 in my extensions instead of 2.0-SNAPSHOT
of maven-site-plugin, because Maven wasn't finding 2.0-SNAPSHOT.
If i just need to use Maven 2.0.5-SNAPSHOT, would you point me to a
build? i'd rather not have to build it myself this weekend.
On 1/27/07, Nathan Bubna [EMAIL PROTECTED] wrote:
:) Great! Well, since our chair was so enthusiastic and he and i
have been doing the recent releases, i'm going to go ahead and make
the changes. if anyone protests, i'll be happy to reverse them
(though that would be a PITA).
On 1/27/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
Nathan Bubna [EMAIL PROTECTED] writes:
With two significant stable releases happening soon (Velocity 1.5 and
VelocityTools 1.3), i'd like to nail down the distribution directory
structure now. Changing these things is a pain due to mirroring,
various link locations and such. I'd rather we get it straight and
stick to it.
+1
Rather than re-hash what's currently out there (which isn't even
totally sync'd with people.apache.org as i write) and our various
understandings of how it should be, i'd like to kick the discussion
off with a proposed structure.
under /dist/velocity, i propose we continue to keep our KEYS file and
directories for engine and tools. directly under those directories,
+1
we should have folders named after the most recent stable/production
release and--if one exists--a more recent unstable/beta release.
+1
Given our current releases, this would look like:
dist/velocity/
KEYS
engine/
1.4/
1.5-beta2/
tools
1.2/
1.3-rc1/
+1
Since all releases on dist are automatically archived, we should not
keep more than one stable and one unstable release for each branch of
a project. So each time there is a stable/production release, both
the old stable release and whatever beta/rc/alpha preceded the new
stable release should be deleted.
+1
The current symlinks VelocityTools has [had in the past] are a
debatable issue. Personally, they're a pain to update, and i suspect
they're not even an ASF endorsed procedure. Unless someone protests,
i'm going to remove them.
+1 +1 +1
If you like this, feel free to give a +1. If you don't please speak
up soon, so i can get things moved around appropriately and update all
our download links accordingly soon. :) If i don't hear anything on
this by Monday afternoon (PST), i'll get started. though, i may do it
earlier if everyone seems to be on board before then. :)
I fully agree with you on all points. Getting this more simple is
good. Getting it consistent is even better.
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]
Re: [VOTE]: Release Velocity 1.5
On 1/27/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Geir Magnusson Jr. [EMAIL PROTECTED] writes: Normally yes - you vote on the final software that's going to be released, not just the concept. At the moment, I have no clue what would actually go out the door wrt the binary (included libs, LICENSE and NOTICE files, etc) Should be easy. Hm. That *is* a strong imbalance IMHO between projects that ship docs as part of their distribution (like we do) and others that simply keep and update their docs online and ship just e.g. javadocs. In that case, I'd actually like to discuss removing all docs except automatically created docs from source (e.g. Javadocs, Changelog etc.) from the distribution archives. -1 i like keeping docs with distros, both source and binary. and as Geir said, it doesn't really solve the problem. We do have to discuss the actual release process. Other projects (e.g. httpd) do it differently, they roll their distribution archives first and then vote on them. We do it the other way around. +1 !! i've been thinking about this for quite some time. i like the freedom httpd-ish projects have to change the status of a release (in any direction) without having to re-roll it. at the latest, i'd like to see us adopt this after Engine 1.5 and Tools 1.3 are out. it's a little superfluous to switch to this now since we've already been stepping through betas and RCS, but if people really wanted to start now, that's fine by me. :) Best regards Henning geir On Jan 27, 2007, at 6:20 AM, Henning P. Schmiedehausen wrote: Geir Magnusson Jr. [EMAIL PROTECTED] writes: I assume we'll have another vote on the final binary? geir Do we need to? The code itself will not change, just some doc file, change logs etc. Best regards Henning On Jan 27, 2007, at 3:52 AM, Henning P. Schmiedehausen wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Hi, I'd say that I fully agree with your points. This is part of the docs cleanup before we release the code. Best regards Henning Hi Henning, +1, with a caveat... Users will want to see specifics of what's new with the system. Where's the change list? Will Maven generate this automatically? I suggest we have two items * a copy of the release notes from the Wiki, moved into the main distro as RELEASE-NOTES.txt. This summarizes key changes and more importantly, dependency changes. * a maven generated list from changes.xml I'm +1 if we have those two things. As an aside, It's incredible all the work you've done, especially in the past few months. WILL On 1/24/07, Malcolm Edgar [EMAIL PROTECTED] wrote: Been waiting for this day for a while now :) +1 On 1/25/07, Nathan Bubna [EMAIL PROTECTED] wrote: +1 On 1/24/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Let's do it. The list of changes (http://issues.apache.org/jira/secure/ReleaseNote.jspa? version=12310253styleName=TextprojectId=12310104Create=Create ) is much longer than it ought to be, the number of open issues is more or less down to zero and no new issues have been reported with beta 2. I think, it is time now. Stuff that I do expect to change between now (CfV) and then (Relase) are all non code: - Further work on the docs - A Maven 2 POM so that the Mavenatics don't need to pull velocity.jar and velocity-dep.jar in all the time - Updates on the xdocs themselves. [ ] +1 Let's do it [ ] 0 I don't care [ ] -1 No, because __ The vote will go for ~72 hours, that is Saturday, 27th, 18:00 MET (http://www.timeanddate.com/worldclock/fixedtime.html? month=1day=27year=2007hour=18min=0sec=0p1=37) My vote is +1 Best regards Henning -- --- 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] -- 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
Re: Release dist directory structure
On 1/27/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: Henning, i've updated all the relevant stuff in velocity/site that i can think of, but i have not been able to successfully build it locally, much less deploy it. Would you mind deploying the updates for me today or tomorrow? Or, if you want to help me figure it out, here's the error i'm stuck on: Redeployed it. BTW: If you are crying out how can I update the site: My plan was to set up an automated rebuild (once or twice a day) on a zone using the maven snapshot. However, the relevant infra ticket is now open for quite a while and even gentle prodding on IRC didn't move it (much). Unless anything happens really quick here, I'm not sure if I get this builder set up before I leave for holidays. Well, that would be nice. If it doesn't happen before you go, and we really need the site updated while you're gone, then i can probably find time to just dig in and build maven 2.0.6 myself. anyway, thanks for updating it for me. :) now i just need www.apache.org and a few mirrors to pick up 1.3-rc1 before i announce it to the lists. :) 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]
Re: Release dist directory structure
On 1/27/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/27/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: Henning, i've updated all the relevant stuff in velocity/site that i can think of, but i have not been able to successfully build it locally, much less deploy it. Would you mind deploying the updates for me today or tomorrow? Or, if you want to help me figure it out, here's the error i'm stuck on: Redeployed it. BTW: If you are crying out how can I update the site: My plan was to set up an automated rebuild (once or twice a day) on a zone using the maven snapshot. However, the relevant infra ticket is now open for quite a while and even gentle prodding on IRC didn't move it (much). Unless anything happens really quick here, I'm not sure if I get this builder set up before I leave for holidays. Well, that would be nice. If it doesn't happen before you go, and we really need the site updated while you're gone, then i can probably find time to just dig in and build maven 2.0.6 myself. ... argh. i checked out the maven 2.0.x head, built it and installed it, but it is still giving me the same error i was getting with 2.0.4. i seem to be stuck at the moment. well, maybe i'll have some time and insight to try again monday... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] VelocityTools 1.3 Release Candidate 1
The Apache Velocity project is pleased to announce the first release candidate for VelocityTools 1.3. You may download this release from: http://velocity.apache.org/download.cgi Significant changes since VelocityTools 1.2 are: - New tools: ContextTool for accessing context data, ResourceTool and ViewResourceTool for resource bundle access and easy i18n - ViewTool and Configurable interfaces are no longer necessary, instead you need only add init(Object) or configure(Map) methods (respectively) to your tools. This has allowed many settings on GenericTools to become configurable via toolbox.xml (like DateTool's default format). - Numerous syntax simplifications for using many of the tools in your templates - New showcase example to demonstrate most of the tools and their functions - Request-scoped tool availability can be restricted according to the request path by adding a request-path element to the tool config. - New functionality in EscapeTool, LinkTool, CookieTool, ValueParser, and more We've also fixed all known bugs, overhauled our build process, updated all dependencies, added a test framework, and much more. Please try it out and let us know of any bugs, so we can release a final 1.3 version as soon as possible! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic Site rebuild
I'd rather not leave something running that is out of our control for a month unless there is very clear need for it, which i don't see at this point. As long as Will's concerns are addressed in the announcement emails and news blurb on the web site, we should be fine until you get back. Besides, i haven't given up all hope of getting Maven 2 to cooperate with me. In a pinch i could probably burn some midnight oil and figure it. On 1/29/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Hi, quick idea: As we will not get the zone on time and I will leave at least my mail server running and connected to the internet, I could set up a once daily / twice daily build on that machine. Downside to it is, that if I get lost in the Outback and it runs amok, you might not be able to stop it (short of closing my people.apache.org account... =:-) ) That would be a temporary solution and there would be no further excuse not to work on the docs. :-) 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]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type ant dist in early March and create the new release. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin\docs [anakia] Input: anakia.xml [anakia] [anakia] Error: The end-tag for element type example must end with a '' delimiter. [anakia]Line: 117 Column: 60 On 1/28/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - 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
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: ... I did discuss this in some depth with Will on IRC. He explained me his reasons for the vote in depth I respect them. Here is my response: - The problem with the anakia.html file is apparent and obvious. So we have a single file for a quite obscure part of Velocity missing. It is fixed on the site (http://velocity.apache.org/engine/releases/velocity-1.5/anakia.html) so if anyone is really looking for this file and can not find it in the downloaded distribution, it is available online. To me, this is no show stopper. It is a wart. We have a number of them (I can readily think of at least one more broken link on the bundled pages). - The release feels rushed. As I wrote, yes in part it is because I want to get it out before end of January. We have been dragging that release for so long that we might make the vaporware top 10 at some point. I'd like to get over with it. If we have warts, we can release 1.5.1 which fix them. Aiming for perfection IMHO does not cut the cake. Good is enough and we can always do the next release. We can find a reason not to release every time we try. +1 - The issues we have are *solely* with documentation. No code is involved. - Re-releasing 1.5 is IMHO not possible. We have rolled tarballs and jars which have been available from http://people.apache.org/dist/velocity/1.5/ Some people are bound to have downloaded them and they might even spread. We can denounce them as not officially released but if we re-roll 1.5 tarballs, we will end up with bug reports against bogus versions. eh... if you think so. i wouldn't say we released it even once, much less worry about re-releasing. we can call the next test build 1.5, 1.5.0 or 1.5.1, as far as i'm concerned. Telling me that I did a lot of work is nice. I know it. Velocity did cut seriously into my spare time lately and I want to spend this time for coding, not doing release and documentation chores. There has not much response been in terms of helping with docs and while most people are already talking about the grand new Velocity 2.0, we want to get an actual release for 1.x first. Sorry, been busy with VelocityTools 1.3. :( BTW: I don't actually buy into the smooth transition argument anyway, however I can not really reinforce it. If you have an app that uses 1.4 or 1.3 for a long time and you just drop 1.5 in, you are in for a surprise. There is always dependency upgrading (which we could have stated more prominently in the release, but we do have it on the web site now (http://velocity.apache.org/engine/devel/upgrading.html, once the mirror caught up), so adding that link in the announcement is IMHO fine. As a compromise, I'd like to propose to keep the 1.5 release and call it Release candidate in the same way as httpd calls it's releases x.y.z and assigns them levels of quality such as (Alpha) (Beta) (Release Candidate) (General Availability). So this would then be Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General Availability) following. hmm. not thrilled about switching release procedures midway, but if you won't release Velocity 1.5 as final/GA/whatever, then i want to see some sort of release. so, i suppose i'll give this plan a: +1 This would mean that we reduce our planned 'press campaign' to an announcement on the dev list and the RSS feed and run the real thing for 1.5.1. I will not release if we have a -1 vote even if we do have three PMC +1 votes. I know the 'Apache rules' would back me here, but I would feel uncomfortable to do this without unanimous consent from the PMC members. Will felt strong enough about this to not just abstain but to vote -1, so we should try to resolve this and get him to retract his vote. To be honest, i'm bummed about this. I think there is wisdom in the rules. If Will feels strongly enough to -1 this, then he should feel strongly enough to address his concerns, upload a 1.5.1 test build and vote to have it released ASAP to supersede the 1.5 release. I did pull the release archives from people.apache.org. If we can resolve this on short notice, good. If not, we are basically stuck with Mid-March as the next possible release date (and a third vote) if I should do the release or someone else stepping up as release manager. Will should be able to scratch his itches quickly. Mid-march is a long time to wait for such small tweaks. If he doesn't step up with a 1.5.1 test build and vote before then, then i may take a shot at it. I'd like to hear opinions from others to that. I'd also like to encourage you to lobby Will to withdraw his -1 :-) Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. no, no. we still like you. just not your decision. :) Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. review and fix away! 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. no. we did have a test build and veltools did not. test build == unreleased build to be tested then voted upon hold on, i'm dropping this email and starting another. we have to get our terms and release processes straight or we'll never find consensus. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors.(no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type ant dist in early March and create the new release. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jan 31, 2007, at 3:48 AM, Will Glass-Husain wrote: I thought about this a little more. There's a couple things we can do that I'd support. (1) Figure out a way to call this release something other than Velocity 1.5, e.g. Velocity 1.5rc1 and issue the release immediately. Can we do this without a 3 day vote? See my other response. Why the rush? If Henning has to go vacation, then you do the RC1 stuff, and we'll wait until he gets back for the 1.5 GA release. (2) Take a little time to make the minor fix required, then release the software. I can step up to do this over the next few days. I think Henning was concerned we'd need to rebuild the site and he's the only one that can do that. If I managed the release, I'd probably want to do Velocity 1.5rc1 first and then Velocity 1.5 two weeks later. Why is he the only one that can do the site? because Maven2 has issues and that's what the current site is being built with. i've tried to get it working on my machine, but no luck yet. (3) Henning remains release manager and we wait until March for the release. We could leave the VELOCITY_1.5_BRANCH up so that the release is ready to go. We can also direct users interested in 1.5 specific features to that svn branch. Right. Do the fixes in the branch, then make a tag/1.5rc1 build, vote and release as RC1. When Henning gets back, do 1.5 GA. Advantage is that people get to beat 1.5RC1 about for a month. geir I'm sure our European community is long abed, I'll look for comments from them in the morning. WILL On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors. (no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed
Release/Voting processes
ok, there seems to be some confusion about the different ways to prepare, label, and vote on releases. here's my understanding of the two most common options. 1) How we used to do it. We would put the quality/status of the release in the release name. These would typically go something like 1.5-beta1, 1.5-rc1, 1.5. If a second beta or RC was necessary, then those would end with a 2. The proper way to begin this release process is to build the distribution with the anticipated release name (say 1.5-beta1) and upload it to where dev@ folks can get it. This is what i would call the test build. Once this test build is available, then call for a simple +1 (release it), 0 (i'm ambivalent), -1 (don't release) vote. This is a perfectly valid process, though it has the disadvantage that the quality/status of the release cannot be changed even if our opinions of it have changed for better or worse. If 1.5-rc1 turned out to have no problems anyone found or cared about, then we would still have to rebuild a release named 1.5, upload the test build of it, and then vote to release it, even though the only needed change was in the name. The improper way to do this is to call for a vote before providing the build for people to test. Henning initially did this with 1.5, and i did it for both Veltools 1.3-beta1 and Veltools 1.3-rc1. That was the lazy, improper way and won't be done again. However, for Henning's second try at 1.5, he did provide a proper test build for us to download and try before voting. 2) How i'd like to see us to do it. We would not put the quality/status of the release in the release name. Instead, the release is only given a number (typically in X.Y.Z form, but there's no reason for that but convention), and the quality/status of the release is decided by vote and labeled on the website and not in the release itself. The proper way to begin this release process is to build the distribution with the current release number and upload it to where dev@ folks can get it. This is, again, the test build. Once the test build is available, the release manager calls for a vote on the quality of the build +1 (GA), +1 (Beta), or +1 (Alpha). I don't really see much point in have a +1 (RC) option, but some like it. Once the vote is over, the release may be made available with the quality determined clearly labeled on the download page and in all announcements. This means that we don't have to do a new release if an RC is found to be perfect. All we have to do is re-vote, change the website, and announce it (if we want). It also provides a clear means to demote releases in which serious problems are later found. This ease of changing status makes it easier to have more frequent releases, and helps to ensure that the work of doing a release is not voided by a -1 vote. Instead, the quality just gets lowered, but the release still happens and is available to those who want it. We've discussed switching to 2), but i'm not aware of a clear decision or consensus on that, so it feels like we're still talking about both, hoping that one or the other will work better for us here. I really want to move to 2), but i've seen on other projects that the switch takes some getting used to. It may be best if we stick to 1) until Velocity 1.5 and Veltools 1.3 are out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/31/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Ok, I didn't want to step on Henning's toes by doing this too soon. I'm guessing he's wrapping up and getting ready for his big trip. We can address the site update immediately following the release. if he's planning to do the fixes and put up a new test build, i haven't heard him say it. at this point, i think it'd be a nice gesture of cooperation if you were to step up and help. Incidentally, the press release is coming along. The PRC has given useful comments. I'm still working on getting a quote from a commercial user. Claude has agreed to be the European contact for the press and I'll be listed as the US contact. that's great! perhaps we could put out a request for commercial soundbites on the user list? WILL On 1/31/07, Nathan Bubna [EMAIL PROTECTED] wrote: If you're willing to do the release, go for it. Put the fixes in the VELOCITY_1.5_BRANCH, roll a test build, upload it, point us to it, and then call for a vote. Updating the site is a secondary thing. We can figure that out when we get to it. - 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]
[VOTE] Release VelocityTools 1.3 Final
No problems new problems have been reported since the release of 1.3-rc1, and i've made another, more thorough pass through the docs and build scripts, so i think we are ready to release 1.3 final. Changes since VelocityTools 1.3-rc1 are as follow: - Improved publish target in build.xml - Added Christopher Schultz to CONTRIBUTORS - Minor misc doc updates - Removed all outdated jakarta URLs i could find - Changed ant scripts to be explicit about compilation source/targets There have been no changes to the source code, test code, or examples since 1.3-rc1. All tests pass successfully, and there are no further features or fixes expected for VelocityTools 1.3. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/1.3/ (i would have put it at people.apache.org/builds/velocity/tools/13, but i don't appear to have the necessary karma, and i don't think it really matters for a test build.) Please download it, try it out, and vote regarding your support for doing this release: [ ] +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 plan to tally the results and close the vote sometime after Thursday 11am PST (roughly 72 hours). My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update on site issues
Hmm. Not sure. I haven't got time to tackle this further today. I'll try again monday and take a look at those. On 2/9/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Stupid question, but are the file permissions right on the public key and containing folder? That always trips me up when logging in with SSH keys. WILL On 2/9/07, Nathan Bubna [EMAIL PROTECTED] wrote: Don't get too excited yet. So, i gave up on trying to get the site plugin to generate the index.html page with the news macro. Instead, i commented out the news macro and manually added the latest news. So now i have the site building and running perfectly on machine. Now i'm caught up trying to deploy the site. I've added my user/pass to the velocity.apache.org server in my M2 settings.xml, but the site:deploy target is failing rather mysteriously: [INFO] [INFO] Building Apache Velocity Site [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] scpexe://people.apache.org/www/velocity.apache.org - Session: Opened Executing command: ssh -o BatchMode yes [EMAIL PROTECTED] mkdir -p /www/velocity.apache.org/. Permission denied (publickey,keyboard-interactive). scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error performing commands for file transfer Exit code 255 - Permission denied (publickey,keyboard-interactive). [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 [INFO] Final Memory: 6M/12M [INFO] I've tried about a dozen different things messing with rsa and dsa keys, adding/removing my password from settings.xml, and more, but no luck yet. I've also tried running the ssh command that is failing, and it only works if i take out the -o BatchMode yes part. Anyone have any ideas? On 2/9/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Good to hear! Glad we have this as a group capability. WILL On 2/8/07, Nathan Bubna [EMAIL PROTECTED] wrote: I've made some progress with building the site. I've managed to get maven (2.0.6-snapshot) to build the web site successfully on my local machine with the exception of the front page, which appears to be failing due to the following error: Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: Cannot find macro with id = null I'm hoping to look further into that today or tomorrow if i have time. I haven't tried deploying the site yet. In the meantime, i've also noticed that there are a number of folders in /www/velocity.apache.org/ that do not have velocity group permissions, so i can't do anything with them. These are the engine/, tools/, and dvsl/ folders. This means i can't add the documentation for the Tools 1.3 release or the devel/ documentation in their current location unless Henning checks this and changes the group perms or someone else with sufficient karma changes them. Anyone out there got that karma? Geir? Or does anyone know who i should talk to? I'm guessing the infrastructure people, but i thought i'd ask here first. The other option would be to change all those locations, but i'd rather not if it can be helped. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] tuc 1.0a1 - URLConnection unit testing framework built for VELTOOLS
nice! i'll try to take a look at it this week. On 2/12/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, In writing unit tests for velocity tools, I needed a component like this and it didn't already seem to exist. So, I created a formal project on sourceforge under the Apache Software License 2.0 and I have an alpha release. The project can be found here: http://sourceforge.net/projects/tuc The only file available for release is tuc-1.0a.zip which contains the full source, small amount of documentation, and a JAR binary for direct use. Unit tests are also provided, and the project is buildable very easily by simply doing ant dist. I'd appreciate any feedback or suggestions for improvements, etc. MY goal is to get this vetted and then used for velocity tools' test suite. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF0Oxq9CaO5/Lv0PARAkRjAJ9rPPyhZpLi1io2qh9DKJeb9hG6XACgkxvp IxCL/7SPHt5sXRcEfCe5MbQ= =05+H -END PGP SIGNATURE- - 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: update on site issues
file permissions on my key don't seem to be the issue. i don't know a ton about ssh perms, but it sure seems like my account just doesn't have the karma to do '-o BatchMode yes'. still looking into it... On 2/9/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Stupid question, but are the file permissions right on the public key and containing folder? That always trips me up when logging in with SSH keys. WILL On 2/9/07, Nathan Bubna [EMAIL PROTECTED] wrote: Don't get too excited yet. So, i gave up on trying to get the site plugin to generate the index.html page with the news macro. Instead, i commented out the news macro and manually added the latest news. So now i have the site building and running perfectly on machine. Now i'm caught up trying to deploy the site. I've added my user/pass to the velocity.apache.org server in my M2 settings.xml, but the site:deploy target is failing rather mysteriously: [INFO] [INFO] Building Apache Velocity Site [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] scpexe://people.apache.org/www/velocity.apache.org - Session: Opened Executing command: ssh -o BatchMode yes [EMAIL PROTECTED] mkdir -p /www/velocity.apache.org/. Permission denied (publickey,keyboard-interactive). scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error performing commands for file transfer Exit code 255 - Permission denied (publickey,keyboard-interactive). [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 [INFO] Final Memory: 6M/12M [INFO] I've tried about a dozen different things messing with rsa and dsa keys, adding/removing my password from settings.xml, and more, but no luck yet. I've also tried running the ssh command that is failing, and it only works if i take out the -o BatchMode yes part. Anyone have any ideas? On 2/9/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Good to hear! Glad we have this as a group capability. WILL On 2/8/07, Nathan Bubna [EMAIL PROTECTED] wrote: I've made some progress with building the site. I've managed to get maven (2.0.6-snapshot) to build the web site successfully on my local machine with the exception of the front page, which appears to be failing due to the following error: Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: Cannot find macro with id = null I'm hoping to look further into that today or tomorrow if i have time. I haven't tried deploying the site yet. In the meantime, i've also noticed that there are a number of folders in /www/velocity.apache.org/ that do not have velocity group permissions, so i can't do anything with them. These are the engine/, tools/, and dvsl/ folders. This means i can't add the documentation for the Tools 1.3 release or the devel/ documentation in their current location unless Henning checks this and changes the group perms or someone else with sufficient karma changes them. Anyone out there got that karma? Geir? Or does anyone know who i should talk to? I'm guessing the infrastructure people, but i thought i'd ask here first. The other option would be to change all those locations, but i'd rather not if it can be helped. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] VelocityTools 1.3 released
I'm pleased to announce the release of VelocityTools 1.3. There have been many improvements made since the 1.2 release. A key focus in this version has been ease of use. We've simplified developing your own tools by eliminating the ViewTool and Configurable interfaces, and we've simplified the syntax for using many of our existing tools within Velocity templates to both save keystrokes and reduce visual clutter. The distribution also comes with a new showcase example webapp that demonstrates many of the uses of the various tools as well as allowing you to interactively play with them. Just download the binary distribution, and deploy the showcase.war example to your servlet container to try it out. Also included are the usual slate of bug fixes, dependency upgrades, entirely new tools, and new functions for existing tools. For a full listing of changes, see the change log. http://velocity.apache.org/tools/devel/changes.html VelocityTools 1.3 is available in either source or binary form at: http://velocity.apache.org/download.cgi#tools For more information about VelocityTools go to: http://velocity.apache.org/tools/devel/index.html Nathan Bubna, on behalf of the Velocity development community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r509094 - in /velocity/engine/trunk/src: java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java test/org/apache/velocity/test/SecureIntrospectionTestCase.java
Awful lot of formatting changes mixed in here, makes it hard to tell
what changed. :(
On 2/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: wglass
Date: Sun Feb 18 21:17:09 2007
New Revision: 509094
URL: http://svn.apache.org/viewvc?view=revrev=509094
Log:
Allow SecureUberspector to work with iterators in #foreach. Fixes VELOCITY-516.
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
velocity/engine/trunk/src/test/org/apache/velocity/test/SecureIntrospectionTestCase.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java?view=diffrev=509094r1=509093r2=509094
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
Sun Feb 18 21:17:09 2007
@@ -16,7 +16,7 @@
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
- * under the License.
+ * under the License.
*/
import java.lang.reflect.Method;
@@ -24,14 +24,14 @@
import org.apache.velocity.runtime.log.Log;
/**
- * pPrevent dangerous classloader/reflection related calls. Use this
+ * pPrevent dangerous classloader/reflection related calls. Use this
* introspector for situations in which template writers are numerous
* or untrusted. Specifically, this introspector prevents creation of
* arbitrary objects and prevents reflection on objects.
- *
- * pSee documentation of checkObjectExecutePermission() for
+ *
+ * pSee documentation of checkObjectExecutePermission() for
* more information on specific classes and methods blocked.
- *
+ *
* @author a href=mailto:[EMAIL PROTECTED]Will Glass-Husain/a
* @version $Id$
*/
@@ -39,19 +39,19 @@
{
private String[] badClasses;
private String[] badPackages;
-
+
public SecureIntrospectorImpl(String[] badClasses, String[] badPackages,
Log log)
{
super(log);
this.badClasses = badClasses;
this.badPackages = badPackages;
}
-
+
/**
- * Get the Method object corresponding to the given class, name and
parameters.
+ * Get the Method object corresponding to the given class, name and
parameters.
* Will check for appropriate execute permissions and return null if the
method
* is not allowed to be executed.
- *
+ *
* @param clazz Class on which method will be called
* @param methodName Name of method to be called
* @param params array of parameters to method
@@ -62,84 +62,81 @@
{
if (!checkObjectExecutePermission(clazz,methodName))
{
-log.warn (Cannot retrieve method + methodName +
+log.warn (Cannot retrieve method + methodName +
from object of class + clazz.getName() +
due to security restrictions.);
return null;
-
+
}
else
{
return super.getMethod(clazz, methodName, params);
}
}
-
+
/**
* Determine which methods and classes to prevent from executing. Always
blocks
* methods wait() and notify(). Always allows methods on Number, Boolean,
and String.
* Prohibits method calls on classes related to reflection and system
operations.
* For the complete list, see the properties
codeintrospector.restrict.classes/code
* and codeintrospector.restrict.packages/code.
- *
+ *
* @param clazz Class on which method will be called
* @param methodName Name of method to be called
* @see
org.apache.velocity.util.introspection.SecureIntrospectorControl#checkObjectExecutePermission(java.lang.Class,
java.lang.String)
*/
public boolean checkObjectExecutePermission(Class clazz, String methodName)
{
-if (methodName == null)
-{
-return false;
-}
-
-/**
- * check for wait and notify
- */
-if ( methodName.equals(wait) || methodName.equals(notify) )
-{
-return false;
-}
-
-/**
- * Always allow the most common classes - Number, Boolean and String
- */
-else if (java.lang.Number.class.isAssignableFrom(clazz))
-{
-return true;
-}
-
-else if (java.lang.Boolean.class.isAssignableFrom(clazz))
-{
-return true;
-}
-
-else if (java.lang.String.class.isAssignableFrom(clazz))
-{
-return true;
-}
-
+
+ /**
+* check for wait
Re: update on site issues
Will, I have pretty good odds on finding time to roll a 1.5 build and call for vote this week. If you can assure me you're sure you can get a test build and vote going tomorrow, i'll hold my horses. If not, then i'm quite tired of waiting for this release and will plan to start putting time into running the release myself tomorrow afternoon. On 2/13/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Nice. Will, are you going to roll Engine 1.5 anytime soon? if not, i might be up for doing it later this week. I think so. I've been getting about 6 hours of sleep nightly for the last few weeks lately due to work deadlines. When that hits 8, I'll have a little free time to address this :-) Give me till this weekend to do the right thing here... WILL On 2/13/07, Nathan Bubna [EMAIL PROTECTED] wrote: finally got it working. the updated site has been uploaded and should be on the public servers soon. i'll probably get an announcement out tomorrow afternoon (too busy between now and then otherwise). for the curious, i finally just wiped my ssh keys on both the server and my client and re-did them following the instructions here: http://www.atmos.albany.edu/facstaff/rmctc/ssh2/ not sure exactly what was wrong before, but it works. Will, are you going to roll Engine 1.5 anytime soon? if not, i might be up for doing it later this week. On 2/13/07, Nathan Bubna [EMAIL PROTECTED] wrote: file permissions on my key don't seem to be the issue. i don't know a ton about ssh perms, but it sure seems like my account just doesn't have the karma to do '-o BatchMode yes'. still looking into it... On 2/9/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Stupid question, but are the file permissions right on the public key and containing folder? That always trips me up when logging in with SSH keys. WILL On 2/9/07, Nathan Bubna [EMAIL PROTECTED] wrote: Don't get too excited yet. So, i gave up on trying to get the site plugin to generate the index.html page with the news macro. Instead, i commented out the news macro and manually added the latest news. So now i have the site building and running perfectly on machine. Now i'm caught up trying to deploy the site. I've added my user/pass to the velocity.apache.org server in my M2 settings.xml, but the site:deploy target is failing rather mysteriously: [INFO] [INFO] Building Apache Velocity Site [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] scpexe://people.apache.org/www/velocity.apache.org - Session: Opened Executing command: ssh -o BatchMode yes [EMAIL PROTECTED] mkdir -p /www/velocity.apache.org/. Permission denied (publickey,keyboard-interactive). scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error performing commands for file transfer Exit code 255 - Permission denied (publickey,keyboard-interactive). [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 [INFO] Final Memory: 6M/12M [INFO] I've tried about a dozen different things messing with rsa and dsa keys, adding/removing my password from settings.xml, and more, but no luck yet. I've also tried running the ssh command that is failing, and it only works if i take out the -o BatchMode yes part. Anyone have any ideas? On 2/9/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Good to hear! Glad we have this as a group capability. WILL On 2/8/07, Nathan Bubna [EMAIL PROTECTED] wrote: I've made some progress with building the site. I've managed to get maven (2.0.6-snapshot) to build the web site successfully on my local machine with the exception of the front page, which appears to be failing due to the following error: Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: Cannot find macro with id = null I'm hoping to look further into that today or tomorrow if i have time. I haven't tried deploying the site yet. In the meantime, i've also noticed that there are a number of folders in /www/velocity.apache.org/ that do not have velocity group permissions, so i can't do anything
[VOTE] Release Velocity Engine 1.5
Ok, Will has fixed the doc issues that made him -1 the last test build, as well as a minor bug in the new SecureUberspect. All the tests pass, the build looks solid to me, and the included velocity-1.5.jar works just dandy with the VelocityTools example apps. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/engine/1.5/ Please check out the build to make sure i haven't missed anything important and vote regarding your support for releasing this test build as the long-awaited Velocity 1.5: [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 10am PST on Saturday, Feb 24th. If i do not find time amidst yardwork that day to finish the release process, then i will do so first thing Monday morning (assuming the vote passes), with the hope that we can announce the release Tuesday morning. My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tools] Some proposals for Tools 2.0
On 2/25/07, Claude Brisson [EMAIL PROTECTED] wrote:
Hi there!
Here are some structural evolutions I'd like to discuss before any
coding. I'm pretty sure that the first one is a good option - the second
one is more prospective.
1. On-demand tools loading: instead of a standard HashMap, the idea here
is to have a ToolMap, inheriting HashMap, which will instanciate a tool
from its toolinfo only when the generic getter is called. This should be
a quite interesting performance gain in some situations. We maybe need
some attribute to have tools instanciated at toolbox initialization
('instanciate-on-load' ?).
I really like the idea! Though, i think i might prefer to call it a
Toolbox instead of ToolMap. just to stick with the metaphor... :)
2. View tools: other objects in my webapp are often jealous of the view
servlet. They also would like to use some of the tools. Session scoped
tools can be reached via the session, but it's not the case for
application or request scoped tools. To achieve this, there would be two
things to do:
- the application tools map should be stored as a ServletContext
attribute and the request tools map as a Request attribute.
- the constitution of the three scoped maps should be decorrelated from
the remaining of the processing so that it could potentially take place
in a servlet filter.
i agree we should find a way to solve this, though i'm not sure i
fully understand the second part of your proposed implementation. i
would think we would simply want to create a Toolbox (as in idea #1)
for each scope, place the proper Toolbox in the attributes of the
request/session/servletcontext and then just make our ChainedContext
smart enough to search in all of those for tools that are requested.
i don't see why we need a filter or to constitute the three toolboxes
at all.
oh, and with this, we may want to re-organize the layout of a
toolbox.xml file to lump the tools from the three scopes together in
their toolboxes. but that's a separate issue...
i predict there are going to be some interesting complications/side
effects, but we'll be able to see those better once we start coding.
i'll try and get a 2.x branch set up today (or soon, if i don't get to
it). Then we can start hacking away. i have some other ideas and
major changes in mind and already have some code for them too. i'm
excited about the possibilities...
Thanks for your remarks,
Claude
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity 1.5 Release - SVN Revision?
I've got to rush out the door to a meeting, but i'll be back in an hour or so. Then i'll comment further, tally the votes and get things moving. And yes, i'm all for a 1.5.1. no shame in that. On 3/6/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: My vote is reluctantly +1, because the I want to get it out weights more for me than the issues that I have found: BTW: Strictly spoken are the references in the POM wrong because they should not reference .../branches/VELOCITY_1.5_BRANCH/ but .../tags/VELOCITY_1.5/ They aren't wrong unless/until we do further dev on the branch, in which case, we should do a 1.5.x release. So, it hardly matters. Yes, it does. If we do further development, then trying to rebuild the site from the release package will give different results. Which probably does not matter much, but it would matter to me. IMHO we will at least have an 1.5.1 to fix the issues listed below: This means that rebuilding 1.5 from source will actually be difficult, once we think about 1.5.1. This is my bad and I intended to fix it before the 1.5 release; however Nathan CfV'ed before I returned from holidays and the voting period is already over. Not too late to vote. 72 hours was the minimum voting period. I'm managing this release, the vote is over when i send a result. Uhm. Don't tempt me. While I'm fed up with delaying and want to have that bugger out, here is what I've found: a) The link problem with the maven site. I have a patch for the guides which will go into trunk shortly. b) The checksum thing. Fixed on the trunk c) The package build thing (restrict on 1.4). I've put a patch on the trunk which might need more discussion. d) The POM references to the branch, not the tag. Considering the fact that Will -1'ed the last release attempt for a documentation issue, personally I'd weight at least d) much more than that. However, I believe that we can release a 1.5.1 4-6 weeks after 1.5 to amend that, so I will not block this vote. I would very much suggest that we target the next tuesday for the official release announcement. This gives us and the mirrors a few days to get our acts together. Lets push this out. Now! Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity 1.5 Release - SVN Revision?
On 3/6/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: My vote is reluctantly +1, because the I want to get it out weights more for me than the issues that I have found: BTW: Strictly spoken are the references in the POM wrong because they should not reference .../branches/VELOCITY_1.5_BRANCH/ but .../tags/VELOCITY_1.5/ They aren't wrong unless/until we do further dev on the branch, in which case, we should do a 1.5.x release. So, it hardly matters. Yes, it does. If we do further development, then trying to rebuild the site from the release package will give different results. Which probably does not matter much, but it would matter to me. i don't see why rebuilding using the source in the release would produce a result different than itself. and what does the site have to do with this? just trying to understand... IMHO we will at least have an 1.5.1 to fix the issues listed below: This means that rebuilding 1.5 from source will actually be difficult, once we think about 1.5.1. This is my bad and I intended to fix it before the 1.5 release; however Nathan CfV'ed before I returned from holidays and the voting period is already over. Not too late to vote. 72 hours was the minimum voting period. I'm managing this release, the vote is over when i send a result. Uhm. Don't tempt me. While I'm fed up with delaying and want to have that bugger out, here is what I've found: a) The link problem with the maven site. I have a patch for the guides which will go into trunk shortly. b) The checksum thing. Fixed on the trunk c) The package build thing (restrict on 1.4). I've put a patch on the trunk which might need more discussion. d) The POM references to the branch, not the tag. Considering the fact that Will -1'ed the last release attempt for a documentation issue, personally I'd weight at least d) much more than that. However, I believe that we can release a 1.5.1 4-6 weeks after 1.5 to amend that, so I will not block this vote. thank you. it's about time we stopped fretting over minor issues in the build and documentation. the goal is always perfection, but the requirement is merely high quality (especially, higher quality than the previous GA release, which we achieved ages ago). I would very much suggest that we target the next tuesday for the official release announcement. This gives us and the mirrors a few days to get our acts together. Will or you can do the official announcement whenever you like. in the meantime, i'll do the result, the push to the mirrors, and the site update ASAP. Lets push this out. Now! Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On 3/6/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: If you'd prefer, i'd be happy to cede the update of the web site to you or at least enlist your help. I've got things working adequately, but not splendidly. Things left to be done for the 1.5 release are: As you wish. I can build it if you want me to. With the zone now finally being available I'm currently setting up ant, maven and all that stuff so we can build from a common environment. that'd be good. if you haven't noticed, i've had to disable the news macro and roughly mimic it's results by hand. if you can make it work properly, i think that would be preferable. of course, i do want us to figure out how to make it work fully for others besides you, but we can do that later. :) - use mvn to deploy the changes i just checked in this morning. i'm waiting until a few more mirrors pick up the build before i do that. Sure. These are changes to the Velocity Site, right? yep. updated the download page, the doap descriptor, the front page and the menu sidebar thing. - update the Engine 1.5 subsection. i'm not entirely sure how you do this. currently, there is an older version (from one of your attempted releases in January, i presume) up at http://velocity.apache.org/engine/releases/velocity-1.5/, but this doesn't reflect any changes since then (e.g. the change log doesn't show the fix for SecureUberspector). i'm not sure yet what the procedure for doing this is. In the engine release, run mvn clean post-site site:deploy. That should push the release version of the site up. This should overwrite all the files you mentioned. let me give this part a try. i haven't done this yet and would like to see it work for me. - create the release tag. That why I asked about the revision. I did svn -m Velocity 1.5 Release copy -r 509925 \ https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH \ https://svn.apache.org/repos/asf/velocity/engine/tags/Velocity_1.5 yeah, i saw that. thanks. for that. I MD5 checked the files from the branch and the tag and they all checked out ok, even though the files on the tag technically have another revision number. that's to be expected. revision numbers are only updated in files which are changed and which have the $Id$ thingy in 'em. - Deploy the release to the maven repo. another thing i've never done. i presume there's a magic maven command for this too? Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On 3/6/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/6/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: If you'd prefer, i'd be happy to cede the update of the web site to you or at least enlist your help. I've got things working adequately, but not splendidly. Things left to be done for the 1.5 release are: As you wish. I can build it if you want me to. With the zone now finally being available I'm currently setting up ant, maven and all that stuff so we can build from a common environment. that'd be good. if you haven't noticed, i've had to disable the news macro and roughly mimic it's results by hand. if you can make it work properly, i think that would be preferable. of course, i do want us to figure out how to make it work fully for others besides you, but we can do that later. ok, i deployed the site using the site module as it is in svn (with the news macro disabled and hand-mimicked). you're of course still quite welcome to re-update with the news macro working, and to fix and bad in-page anchors or whatever. so, the public now has access to Velocity 1.5 from our download page, if they happen to visit the web site before the announcements go out by email. - use mvn to deploy the changes i just checked in this morning. i'm waiting until a few more mirrors pick up the build before i do that. Sure. These are changes to the Velocity Site, right? yep. updated the download page, the doap descriptor, the front page and the menu sidebar thing. - update the Engine 1.5 subsection. i'm not entirely sure how you do this. currently, there is an older version (from one of your attempted releases in January, i presume) up at http://velocity.apache.org/engine/releases/velocity-1.5/, but this doesn't reflect any changes since then (e.g. the change log doesn't show the fix for SecureUberspector). i'm not sure yet what the procedure for doing this is. In the engine release, run mvn clean post-site site:deploy. That should push the release version of the site up. This should overwrite all the files you mentioned. let me give this part a try. i haven't done this yet and would like to see it work for me. it appears to have worked just fine... - create the release tag. That why I asked about the revision. I did svn -m Velocity 1.5 Release copy -r 509925 \ https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH \ https://svn.apache.org/repos/asf/velocity/engine/tags/Velocity_1.5 yeah, i saw that. thanks. for that. I MD5 checked the files from the branch and the tag and they all checked out ok, even though the files on the tag technically have another revision number. that's to be expected. revision numbers are only updated in files which are changed and which have the $Id$ thingy in 'em. - Deploy the release to the maven repo. another thing i've never done. i presume there's a magic maven command for this too? i think this last item and the email announcements are all that's left to be done. Will said he'd handle the PR. Anyone who wants to deploy 1.5 to the maven repo or tell me how to do it is welcome to do so. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
I don't mind much either way, but i was given the impression from previous discussion that first thing Tuesday morning (presumably east coast time) was the ideal time for that. On 3/6/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Do you want me to send the email announcements? I can do this tonight. WILL On 3/6/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/6/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/6/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: If you'd prefer, i'd be happy to cede the update of the web site to you or at least enlist your help. I've got things working adequately, but not splendidly. Things left to be done for the 1.5 release are: As you wish. I can build it if you want me to. With the zone now finally being available I'm currently setting up ant, maven and all that stuff so we can build from a common environment. that'd be good. if you haven't noticed, i've had to disable the news macro and roughly mimic it's results by hand. if you can make it work properly, i think that would be preferable. of course, i do want us to figure out how to make it work fully for others besides you, but we can do that later. ok, i deployed the site using the site module as it is in svn (with the news macro disabled and hand-mimicked). you're of course still quite welcome to re-update with the news macro working, and to fix and bad in-page anchors or whatever. so, the public now has access to Velocity 1.5 from our download page, if they happen to visit the web site before the announcements go out by email. - use mvn to deploy the changes i just checked in this morning. i'm waiting until a few more mirrors pick up the build before i do that. Sure. These are changes to the Velocity Site, right? yep. updated the download page, the doap descriptor, the front page and the menu sidebar thing. - update the Engine 1.5 subsection. i'm not entirely sure how you do this. currently, there is an older version (from one of your attempted releases in January, i presume) up at http://velocity.apache.org/engine/releases/velocity-1.5/, but this doesn't reflect any changes since then (e.g. the change log doesn't show the fix for SecureUberspector). i'm not sure yet what the procedure for doing this is. In the engine release, run mvn clean post-site site:deploy. That should push the release version of the site up. This should overwrite all the files you mentioned. let me give this part a try. i haven't done this yet and would like to see it work for me. it appears to have worked just fine... - create the release tag. That why I asked about the revision. I did svn -m Velocity 1.5 Release copy -r 509925 \ https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH\ https://svn.apache.org/repos/asf/velocity/engine/tags/Velocity_1.5 yeah, i saw that. thanks. for that. I MD5 checked the files from the branch and the tag and they all checked out ok, even though the files on the tag technically have another revision number. that's to be expected. revision numbers are only updated in files which are changed and which have the $Id$ thingy in 'em. - Deploy the release to the maven repo. another thing i've never done. i presume there's a magic maven command for this too? i think this last item and the email announcements are all that's left to be done. Will said he'd handle the PR. Anyone who wants to deploy 1.5 to the maven repo or tell me how to do it is welcome to do so. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On 3/7/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: i noticed that there weren't many there, but i couldn't remember if there were a lot beforehand. (i.e. i didn't know if my update introduced that or not). I've deployed both sites again, they should be fine now. thanks again! feel free to use me as a guinea pig to test out you changes as you smooth things out. i want to make sure i can update the site as well. also, it would be good to switch the veltools docs to the same process eventually (once i trust it), so the more i figure this out the better. i do at least see that this has more potential than the old process. it's just been a very, very rough learning curve. Now that we have the engine release, I will put the jar into the maven repos how is this done? and once they show up, I will try to smooth out the site tools, release them and then the building should be much easier, because all the plugins then come from the repo. looking forward to it! I will upgrade to maven 2.0.5 shortly and look whether all my patches made it in (at least the relative path generation path still has some aches with the maven folks. Without it, the breadcrumbs for the tools don't work unfortunately). Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r517553 [1/2] - in
I agree that this is not part of the public API, and i'm ok with the change. However, we need to make sure this is very well-documented, so that those who do more heavy hacking on Velocity get warning of the change. And, if it's easy/trivial to add a deprecation path, that wouldn't hurt anything. On 3/13/07, Will Glass-Husain [EMAIL PROTECTED] wrote: How so? I moved ParserVisitor back into the node package, where it was in v1.4. Since it's not part of the public API, shouldn't matter. (Am I right?) We got into trouble with this before by moving the Node object, which is part of the Directive API. WILL On 3/13/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Uhm, while I agree with that patch, you are aware that this is non-backwards compatible? Author: wglass Date: Mon Mar 12 23:09:58 2007 New Revision: 517553 URL: http://svn.apache.org/viewvc?view=revrev=517553 Log: move ParserVisitor to node package to avoid being overwritten by javacc. Added: velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ParserVisitor.java - copied, changed from r517533, velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/ParserVisitor.java Removed: Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Google Summer of Code project idea request
There are some grammatical/spelling issues*, but on the whole it looks good to me. *On spelling, change cashing to caching. If you want grammar corrections let me know, and i can go through it again and send you a list later today. On 3/21/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, I have almost completed my proposal for Veocimacro improvements. It is in http://wiki.apache.org/general/GSOC2007/Supun/Velocimacro. I'd really appreciate, if anyone can look in to that. I'm pretty sure there are lot of things that can be improved. Thanks, Supun Kamburugamuva. On 3/18/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Interesting idea. We need to be sure the scope is broad enough for a full GSOC project. For more info, I've been browsing http://wiki.apache.org/general/SummerOfCode2007 I'll write up both of these ideas and add them to the list, putting my name down as mentor. If anyone else is interesting I'd be happy to have company. Supun, if you're interested you'll have to develop a detailed application. If you post your application to the list ahead of time (before the deadline) we can help you refine it. WILL On 3/17/07, Malcolm Edgar [EMAIL PROTECTED] wrote: +1 on the Performance project. There are some great tools for profiling applications now with open source licenses. As a student, you also will learn a great deal from this project. The things you learn from profiling are very interesting, having been involved in a 2 month project performance optimisation on a CRM system, it was one of the best development learning experiences I have had. regards Malcolm Edgar http://click.sourceforge.net On 3/16/07, Ahmed Mohombe [EMAIL PROTECTED] wrote: Ideas from the community? What about some *real* performance improvements? 4 years ago, when Velocity gained a big number of users, it was because Velocity was much faster than JSP. This is not true anymore, as JSP is much faster and scalable now. Maybe it would be the time to try to regain a part of your users with a Performance Improvements Project. Of course, it doesn't sounds spectacular, but the effect would be one for sure :). Velocity needs really almost no new features(except better error reporting and whitespace control), but better speed is always good. Ahmed. P.S. I don't expect Velocity to be again faster than JSP (it was up to 5 times faster in the past), but now the situation is almost reversed, so reducing the gap a little would be great. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tools] Some proposals for Tools 2.0
On 2/26/07, Nathan Bubna [EMAIL PROTECTED] wrote:
On 2/25/07, Claude Brisson [EMAIL PROTECTED] wrote:
Hi there!
Here are some structural evolutions I'd like to discuss before any
coding. I'm pretty sure that the first one is a good option - the second
one is more prospective.
1. On-demand tools loading: instead of a standard HashMap, the idea here
is to have a ToolMap, inheriting HashMap, which will instanciate a tool
from its toolinfo only when the generic getter is called. This should be
a quite interesting performance gain in some situations. We maybe need
some attribute to have tools instanciated at toolbox initialization
('instanciate-on-load' ?).
I really like the idea! Though, i think i might prefer to call it a
Toolbox instead of ToolMap. just to stick with the metaphor... :)
2. View tools: other objects in my webapp are often jealous of the view
servlet. They also would like to use some of the tools. Session scoped
tools can be reached via the session, but it's not the case for
application or request scoped tools. To achieve this, there would be two
things to do:
- the application tools map should be stored as a ServletContext
attribute and the request tools map as a Request attribute.
- the constitution of the three scoped maps should be decorrelated from
the remaining of the processing so that it could potentially take place
in a servlet filter.
i agree we should find a way to solve this, though i'm not sure i
fully understand the second part of your proposed implementation. i
would think we would simply want to create a Toolbox (as in idea #1)
for each scope, place the proper Toolbox in the attributes of the
request/session/servletcontext and then just make our ChainedContext
smart enough to search in all of those for tools that are requested.
i don't see why we need a filter or to constitute the three toolboxes
at all.
oh, and with this, we may want to re-organize the layout of a
toolbox.xml file to lump the tools from the three scopes together in
their toolboxes. but that's a separate issue...
i predict there are going to be some interesting complications/side
effects, but we'll be able to see those better once we start coding.
i'll try and get a 2.x branch set up today (or soon, if i don't get to
it). Then we can start hacking away. i have some other ideas and
major changes in mind and already have some code for them too. i'm
excited about the possibilities...
ok, so i started working on this last week, and got further than
anticipated. this week, i've had a little time to refine some things,
so i want to start checking stuff in a bit later today. i've probably
already done more than i ought to have without checking stuff in.
at this point, i'm not thinking extensively about backwards
compatibility, but i do hope to address that eventually. i just
wanted to give a little heads up that some of this stuff is going to
start coming into the 2.x branch today. also, please note that it
compiles with jdk 1.5 and velocity 1.5, but is not yet fully useable
nor have i written tests for the new stuff yet.i do plan to write
tests, and i'm thinking about jdk 1.4 support as well. i'm not
planning to support pre-1.5 Velocity though.
feedback is welcome, as are contributions.
oh, and in case anyone is concerned, i have no plans to stop
developing the 1.x branch. i'm just exploring the possibilities for
2.x.
Thanks for your remarks,
Claude
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tools] Some proposals for Tools 2.0
On 3/22/07, Claude Brisson [EMAIL PROTECTED] wrote: Le jeudi 22 mars 2007 à 09:26 -0700, Nathan Bubna a écrit : snip/ Oh, responding to one of your previous points: i don't see why we need a filter or to constitute the three toolboxes at all. It's a need I frequently encountered. Quite simple in fact. If the toolbox manager can be initialized before the view servlet is reached (and for instance from an early filter but the filter itself need not to be provided), then other objects in the webapp (other filters, controller objects) can reach constants and tools defined in the three toolboxes. It just boils down to avoid re-initializing one of the three toolboxes when we read the view servlet. Take a look at what i've done so far, when you get a chance. We're close to what you want already, i think. The VelocityView class can be easily used in a filter as it is, and once we have the toolboxes in the request/session/application attributes, then we can access them from any servlet or filter. So, we would just need to create a VelocityViewFilter that initializes the VelocityView when it is init'ed, and then calls velocityView.prepareToolboxes(request) for every request it handles. I'm about to check in some refinements to the prepareToolboxes() stuff (to control the key used to store the toolboxes, so they can be shared or unique to the VelocityView. We might also consider supporting the option of putting the initialized VelocityView into the application attributes so that any Filter/Servlet/Tag can share it, rather than having to initialize their own. This would be more efficient than the current approach of just sharing Toolboxes between VelocityViews. there are many ways to skin this cat. the trick will be choosing the best as a default, and making it easy to do things differently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity DocBook Framework 1.0
+1 On 3/21/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: [Let's say, it will not get better and I'm already bored out of my mind again tinkering with XSL and XML.] This is the CfV for the first release of the Velocity DocBook Framework. It is intended for creating and maintaining high quality documentation generated in the DocBook format. The framework itself is completely generic, non-intrusive, 100% bio-degradable and environment-friendly. The release candidate is available from http://people.apache.org/~henning/DocBook-Framework/ The documentation (which also serves as showcase example is visible at http://people.apache.org/~henning/DocBook-Framework/DocBook-Framework-1.0.pdf) [ ] +1 Let's do it [ ] 0 I don't care. [ ] -1 No, because __ Voting period is until Sunday, March 25th, 2007, 12:00 CEST ( 72h). My vote is +1 Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google Summer of Code project idea request
Cool, things have improved; i only found two more clear grammar problems: - In the Project Details section, the start of the last sentence in the third paragraph needs to change from If the values is True to If the value is True. - In the third sentence of the Maximum recursive depths paragraph, use property should be use a property. Also, i have a few technical comments that i did not think of before. In the Argument overloading section of the Project details, it is not clear whether you intend to change it so users can define multiple macros with the same name but different argument types (so arguments are passed by value) or whether you simply intend to allow users to define multiple macros with the same name but which accept different numbers of arguments (which would still be passed by name). You may consider clarifying that paragraph to clearly mean that latter option, as that is the desired feature, while the former is definitely not wanted. I'm also not entirely clear what the Passing expressions as arguments section is about. Is there a JIRA issue or Wiki entry about this that you can point to as a reference for me to understand this? What sort expressions are you concerned with? You already can do things like #fooMacro( $this.is.anExpression() ). Finally, one very common feature request for Velocimacros that would be very appreciated, is to allow users to define Velocimacros that take bodies. So i could do something like #macro( toDiv $class ) div class=$class#body/div #end and use it like: #toDiv( 'foo' )This is the body.#end to produce div class=fooThis is the body./div If you were interested in working on this feature, you'd be my hero! Of course, that's your decision... :) On 3/23/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, Thanks for the effort. I have corrected most of the spelling issues and grammatical issues. If you have time please go thought it. Thanks, Supun.. On 3/22/07, Nathan Bubna [EMAIL PROTECTED] wrote: There are some grammatical/spelling issues*, but on the whole it looks good to me. *On spelling, change cashing to caching. If you want grammar corrections let me know, and i can go through it again and send you a list later today. On 3/21/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, I have almost completed my proposal for Veocimacro improvements. It is in http://wiki.apache.org/general/GSOC2007/Supun/Velocimacro. I'd really appreciate, if anyone can look in to that. I'm pretty sure there are lot of things that can be improved. Thanks, Supun Kamburugamuva. On 3/18/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Interesting idea. We need to be sure the scope is broad enough for a full GSOC project. For more info, I've been browsing http://wiki.apache.org/general/SummerOfCode2007 I'll write up both of these ideas and add them to the list, putting my name down as mentor. If anyone else is interesting I'd be happy to have company. Supun, if you're interested you'll have to develop a detailed application. If you post your application to the list ahead of time (before the deadline) we can help you refine it. WILL On 3/17/07, Malcolm Edgar [EMAIL PROTECTED] wrote: +1 on the Performance project. There are some great tools for profiling applications now with open source licenses. As a student, you also will learn a great deal from this project. The things you learn from profiling are very interesting, having been involved in a 2 month project performance optimisation on a CRM system, it was one of the best development learning experiences I have had. regards Malcolm Edgar http://click.sourceforge.net On 3/16/07, Ahmed Mohombe [EMAIL PROTECTED] wrote: Ideas from the community? What about some *real* performance improvements? 4 years ago, when Velocity gained a big number of users, it was because Velocity was much faster than JSP. This is not true anymore, as JSP is much faster and scalable now. Maybe it would be the time to try to regain a part of your users with a Performance Improvements Project. Of course, it doesn't sounds spectacular, but the effect would be one for sure :). Velocity needs really almost no new features(except better error reporting and whitespace control), but better speed is always good. Ahmed. P.S. I don't expect Velocity to be again faster than JSP (it was up to 5 times faster in the past), but now the situation is almost reversed, so reducing the gap a little would be great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [Tools] Some proposals for Tools 2.0
On 3/23/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, Nathan Bubna wrote: The VelocityView class can be easily used in a filter as it is, and once we have the toolboxes in the request/session/application attributes, then we can access them from any servlet or filter. So, we would just need to create a VelocityViewFilter that initializes the VelocityView when it is init'ed, and then calls velocityView.prepareToolboxes(request) for every request it handles. I think a better architecture would be to create a helper class that is called by either VelocityViewServlet or VelocityToolboxFilter (a better name IMHO), instead of actually initializing a VelocityViewServlet inside the filter just for the purposes of accessing a prepareToolboxes method. like this one? http://svn.apache.org/viewvc/velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/view/VelocityView.java?view=markup i never said anything about initializing a servlet within a filter. ;-) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBA8N9CaO5/Lv0PARAmNeAKCfiZ9jMenTeRt0YlV8G2VPF6BGPgCfQeyN uewxL04gwK9RLmQIhVpB4m4= =VRUm -END PGP SIGNATURE- - 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: Google Summer of Code project idea request
ah, expressions with operators... yeah, that's something we'd probably want to support for method, macro, and directive parameters all at once, to minimize con fusion about where thos are allowed. i suppose they already are allowed in some (all?) directives though. On 3/24/07, Will Glass-Husain [EMAIL PROTECTED] wrote: I thought there was a JIRA issue on this, but I was mistaken. I was thinking it'd be nice to support #someMacro (10 + 10) but I don't feel strongly about it. Actually, on a related topic, I'd really like to see us add syntax for expressions in method calls. I do this all the time (generating a syntax error). $Tool.someMethod($velocityCount - 1) or similar. WILL On 3/24/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/24/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, Thanks for the feedback. I'll add those additions and corrections. I think adding the capability to pass expressions to macros make them more complete. So I'll stick to my orginal proposal. I still don't know what this refers to. Will? I understand this was your suggestion? What sort of expressions are you talking about? Thanks, Supun.. On 3/23/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Supun, Really a very nice proposal. I think it'd be helpful to link at the end a list of relevant JIRA issues and wiki pages. It looks like (among other things) you are referring to http://wiki.apache.org/velocity/MacroIssues You list 'All the improvements to the code should not destroy the backward compatibility of the Velocity engine, and it shouldn't affect the Velocity engines template caching mechanism. These are two challenging issues that need to be addressed with care' I want to suggest a third requirement, which is that performance should not be significantly affected. This is really related to the caching issue. I think the allow expressions in macro arguments idea is nice, but not essential. (yes, I know this was my suggestion). Nathan's point about macro bodies might be more relevant. But I encourage you to follow your interests here. Best, WILL On 3/23/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, Thanks for the effort. I have corrected most of the spelling issues and grammatical issues. If you have time please go thought it. Thanks, Supun.. On 3/22/07, Nathan Bubna [EMAIL PROTECTED] wrote: There are some grammatical/spelling issues*, but on the whole it looks good to me. *On spelling, change cashing to caching. If you want grammar corrections let me know, and i can go through it again and send you a list later today. On 3/21/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, I have almost completed my proposal for Veocimacro improvements. It is in http://wiki.apache.org/general/GSOC2007/Supun/Velocimacro. I'd really appreciate, if anyone can look in to that. I'm pretty sure there are lot of things that can be improved. Thanks, Supun Kamburugamuva. On 3/18/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Interesting idea. We need to be sure the scope is broad enough for a full GSOC project. For more info, I've been browsing http://wiki.apache.org/general/SummerOfCode2007 I'll write up both of these ideas and add them to the list, putting my name down as mentor. If anyone else is interesting I'd be happy to have company. Supun, if you're interested you'll have to develop a detailed application. If you post your application to the list ahead of time (before the deadline) we can help you refine it. WILL On 3/17/07, Malcolm Edgar [EMAIL PROTECTED] wrote: +1 on the Performance project. There are some great tools for profiling applications now with open source licenses. As a student, you also will learn a great deal from this project. The things you learn from profiling are very interesting, having been involved in a 2 month project performance optimisation on a CRM system, it was one of the best development learning experiences I have had. regards Malcolm Edgar http://click.sourceforge.net On 3/16/07, Ahmed Mohombe [EMAIL PROTECTED] wrote: Ideas from the community? What about some *real* performance improvements? 4 years ago, when Velocity gained a big number of users, it was because Velocity was much faster than JSP. This is not true anymore, as JSP is much faster and scalable now. Maybe it would be the time to try to regain a part of your users with a Performance Improvements Project. Of course, it doesn't sounds spectacular, but the effect would be one
Re: whither 1.6?
On 3/26/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Good thoughts. There's a few interesting Texen improvements in JIRA. Making Texen a separate project will be motivating to get those committed. I like the idea of doing a 1.0 release on the current (post-migration) code base, then adding new features. For completeness, I'd like to see us do a release of DVSL as well. I'll help with all this. The treat arrays like lists, support iterables, support vararg also seem good improvements on usability. Are all these items in JIRA? they are now. WILL On 3/26/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/25/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Colleagues, What should we aim for with Velocity 1.6? I feel that we've cleaned up most urgent bugs and pressing issues with the 1.5 release. Given the sporadic nature of our development efforts, timelines are a little risky. Still, I was thinking it'd be nice to do a release of 1.6 this fall. if not before. :) JIRA lists 38 issues with a 1.6 target. There's a few bugs and a lot of incremental feature suggestions, few with actual code. Many of these enhancement requests will likely get bumped back unless someone champions them. https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310104fixfor=12310290 What issues do our committer and developer community care about? the ones they work on. :) myself, i'm interested in helping to pull out Texen, do a 1.0 release immediately after the move, and then start improving it. also, i'm thinking about setting aside some time to work on a way to make Velocity treat lists and arrays as much like fixed-length lists as possible, so that template authors needn't bother about the difference. and yeah, i think that can be done in a B.C. manner. oh, i'm also interested in exploring ideas for supporting Iterable in #foreach and varargs in method calls (i.e. key JDK 1.5 improvements) without the need to resort to stuff on the whiteboard. JDK 6 is out and many companies (mine included) now dev against 1.5. I'd like to see these supported out-of-the-box, if at all possible. I think we should have modest goals. Myself, I mostly want to see the macro issues addressed. I'd also like to clean up the project, split out Texen and Anakia (per Henning's suggestions on maintaining compatibility). I've written up a few notes at http://wiki.apache.org/velocity/RoadMap If one of the committers (Henning?) becomes fired up, we could start a 2.0 branch, though I confess that personally I'm more interested in incremental development. for the moment, i am too. it's currently only the whitespace stuff that makes me itch to move on to 2.0... WILL -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r523108 - /velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java
On 3/27/07, Will Glass-Husain [EMAIL PROTECTED] wrote:
Does this mean a decimal number is supported in an integer range?
yeah, it just takes the intValue(). i was a little surprised at this
at first, until i realized it basically makes it so that template
authors needn't care about the number's type. numbers just work. i
like that. :)
WILL
On 3/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: dlr
Date: Tue Mar 27 16:07:08 2007
New Revision: 523108
URL: http://svn.apache.org/viewvc?view=revrev=523108
Log:
* src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java
(value): Support use of any sub-class of java.lang.Number as an end
of the integer values used to compose a range.
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java?view=diffrev=523108r1=523107r2=523108
==
---
velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTIntegerRange.java
Tue Mar 27 16:07:08 2007
@@ -97,13 +97,13 @@
* if not an Integer, not much we can do either
*/
-if ( !( left instanceof Integer ) || !( right instanceof Integer ))
+if ( !( left instanceof Number ) || !( right instanceof Number ))
{
-log.error((!(left instanceof Integer) ? Left : Right)
+log.error((!(left instanceof Number) ? Left : Right)
+ side of range operator is not a valid type.
- + Currently only integers (1,2,3...) and Integer type
is supported.
+ + Currently only integers (1,2,3...) and the
Numbertype is supported.
+ context.getCurrentTemplateName() + [line +
getLine()
- + , column + getColumn() + ]);
+ + , column + getColumn() + ']');
return null;
}
@@ -113,8 +113,8 @@
* get the two integer values of the ends of the range
*/
-int l = ( (Integer) left ).intValue() ;
-int r = ( (Integer) right ).intValue();
+int l = ((Number) left).intValue() ;
+int r = ((Number) right).intValue();
/*
* find out how many there are
--
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]
moving LogChutes from Tools to Engine
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]
Re: svn commit: r525698 - in /velocity/engine/trunk/src:
On 4/8/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
While I hope to grasp the intention of this patch; why can't you wrap
the Array into Arrays.asList(), which does turn an array into a fixed
size list?
i believe that would break $object.expectsArray($array)
Best regards
Henning
Author: nbubna
Date: Wed Apr 4 22:03:07 2007
New Revision: 525698
URL: http://svn.apache.org/viewvc?view=revrev=525698
Log:
VELTOOLS-533: initial support for treating arrays like fixed-size lists
Added:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/VelArrayMethod.java
(with props)
velocity/engine/trunk/src/test/org/apache/velocity/test/ArrayMethodsTestCase.java
(with props)
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java?view=diffrev=525698r1=525697r2=525698
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
Wed Apr 4 22:03:07 2007
@@ -163,8 +163,19 @@
}
Method m = introspector.getMethod(obj.getClass(), methodName, args);
-
-return (m != null) ? new VelMethodImpl(m) : null;
+if (m != null)
+{
+return new VelMethodImpl(m);
+}
+else if (obj.getClass().isArray())
+{
+// only return *supported* array methods
+if (VelArrayMethod.supports(methodName, args))
+{
+return new VelArrayMethod(obj.getClass(), methodName, args);
+}
+}
+return null;
}
/**
Added:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/VelArrayMethod.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/VelArrayMethod.java?view=autorev=525698
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/VelArrayMethod.java
(added)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/VelArrayMethod.java
Wed Apr 4 22:03:07 2007
@@ -0,0 +1,173 @@
+package org.apache.velocity.util.introspection;
+
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License)
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import java.lang.reflect.Array;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.util.List;
+
+/**
+ * Implementation of VelMethod to provide introspective methods for
+ * arrays that match those that would work on a fixed-size [EMAIL PROTECTED]
List}.
+ * Currently only size(), isEmpty(), get(int), and set(int,Object) are
+ * supported. Later, support may be added for other read-only methods
+ * such as contains(Object) or subList(int,int). Patches are welcome! :)
+ *
+ * @author Nathan Bubna
+ * @version $Id: VelArrayMethod.java 440740 2006-09-06 15:37:44Z nbubna $
+ */
+public class VelArrayMethod implements VelMethod
+{
+public static String SIZE = size;
+public static String IS_EMPTY = isEmpty;
+public static String GET = get;
+public static String SET = set;
+
+public static boolean supports(String methodName, Object[] params)
+{
+// quickest way to narrow things down is to switch
+// on the number of parameters
+switch (params.length)
+{
+case 0:
+// then they must be calling one of these
+return SIZE.equals(methodName) || IS_EMPTY.equals(methodName);
+case 1:
+// must be get() with a numeric param
+return GET.equals(methodName) isNumeric(params[0]);
+case 2:
+// must be set() with a numeric first param
+return SET.equals(methodName) isNumeric(params[0]);
+default:
+// it's not a supported method
+return false;
+}
+}
+
+protected static boolean isNumeric(Object param
Re: svn commit: r524893 - in /velocity/engine/trunk: build/build.properties
See r524894 On 4/8/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Author: nbubna Date: Mon Apr 2 12:27:29 2007 New Revision: 524893 [...] # Needs to be configured with system location of javacc for parser task -javacc.home= *unset* +javacc.home= C:/java/java.net/javacc That one slipped you through. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r525698 - in /velocity/engine/trunk/src:
On 4/10/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
Nathan Bubna [EMAIL PROTECTED] writes:
On 4/8/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
While I hope to grasp the intention of this patch; why can't you wrap
the Array into Arrays.asList(), which does turn an array into a fixed
size list?
i should have asked this the first time, but where do you see this
wrapping happening?
i believe that would break $object.expectsArray($array)
No it does not. But it breaks in better ways. ;-)
having trouble parsing this paragraph...
Actually, the primitive types are the problem. For Object arrays, using asArray
is a piece of cake. However, for simple types, you can not cast to Object [], so
Arrays.asArray is out of the question, but I tried this abomination:
if (Object [].class.isAssignableFrom(klass))
{
return Arrays.asList((Object []) obj);
} else if (boolean [].class.isAssignableFrom(klass))
{
return Arrays.asList(ArrayUtils.toObject((boolean []) obj));
} else [... all primitives to short ...]
}
where are you putting this code?
which *does* work until you get to your primitive setter test. The
ArrayUtils.toObject method created a new array on the fly which
contains the primitive values as objects. And the setters change the
object but not the corresponding primitive. So this test fails and I
see no quick way of fixing.
if you can get it to work, i'm definitely open to other
implementations. my only concern is to enable this functionality (and
more if possible).
I still hate the implementation of the Array Method; this must be
easier/more elegant to implement. Will have to think about this,
though. Something like an array proxy that implements List and
converts on the fly. Having a separate VelArrayMethod feels wrong.
would it help to call it VelPretendMethod? ;-)
when i get a little more time to re-read the above (and your answers
to my questions about it), i'll see if i can't come up with something
more palatable to you. :) right now, i'm a little brain-fried.
Best regards
Henning
--
Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux,
|gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n
Save the cheerleader. Save the world.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: welcome!
Congrats on getting your application accepted! On 4/13/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Dear Supun, Welcome to the Velocity community! You've probably already heard that your application for Google Summer of Code 2007 has been accepted. As your official mentor I'm sending you a public welcome note and ideas for getting started. (I'll send you a smaller private note with personal contact info as well). I send this publically as I hope you will build a relationship not just with me but with the entire developer community. A little bit about me. I work in San Francisco, California for a small startup of which I am co-owner, Forio Business Simulations. (www.forio.com). We sell a product and hosted service which enables third parties to create a specific type of web application (business simulations) for their clients. Velocity is a key part of our platform with hundreds of users uploading their own dynamic web pages marked up with a Velocity-based language. My involvement with the project started in 2002 when I got frustrated with some missing pieces of the language. First I complained. Then I wrote a few patches. Most notably, I helped add decimal number support to the library, added new event handlers, and wrote a security-oriented introspector. While I waited for the patches to be reviewed and committed, I became active on the user lists answering questions. Eventually I was given committer privileges and became interested in the project beyond my immediate needs. Several other new committers were added around the same time, and we applied to become an Apache Top Level Project (TLP). As a consequence of all the above, this part March the project issued the first new release of Velocity in 3 years. Back to topic... This is my first time mentoring, so appreciate any advice from you as to how I can be supportive as we go along. My two big suggestions are (1) stay in touch and (2) stay public. In other words, don't hide away and code, but instead send regular updates and ask lots of questions. If you are going to go away (holiday, family, etc) for a while, let us know. Also, please involve the entire community by using public channels whenever possible. Correspond on [EMAIL PROTECTED] Submit patches and comments on issues via JIRA. And feel free to be involved with other aspects of the project (e.g. answering user questions on [EMAIL PROTECTED] if you feel inclined). I also want to note that your proposed project consists of a number of mostly independent pieces. I encourage you to do them one at a time and keep them all separate when discussing and when submitting patches. This simplifies discussion and makes it easier to review code. Also, we're very religious about code style and about unit tests. Every new feature or bug fix will need a unit test in order to be committed. Here's a couple of specific suggestions I have for you to get started. I note that the official coding period doesn't start until May 28. (1) Subscribe to the dev and user mailing lists. http://velocity.apache.org/contact.html (2) Introduce yourself on the dev list. Where do you go to school? How'd you start using Velocity? What do you plan to do first? (3) Checkout the latest Velocity engine code base with svn if you haven't already http://www.apache.org/dev/version-control.html (4) Read these guidelines for community and coding standards. http://wiki.apache.org/velocity/GettingYourPatchCommitted http://wiki.apache.org/velocity/CodeStandards http://wiki.apache.org/velocity/DocumentationGuidelines (5) Pick one aspect of your project, and jump in! Welcome again Supun -- look forward to working with you over the following few months. Best regards. WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Header.vm file on Locale change
Please don't cross-post. This is a user list question. Wait a few days to get a reply there before you try this list. 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 meta 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 dont know how to use it in header.vm. 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-tf3589049.html#a10029910 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing Header.vm file on Locale change
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 meta 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 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)) !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head base href=#BaseHref() meta http-equiv=Content-type content=#ContentType() / meta http-equiv=Content-style-type content=text/css / #includeJavaScriptForHead() #IncludeStylesheets() #if($langname== it) metaitalian meta data here/meta #else metaenglish meta data here/meta #end head 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 meta 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
Re: svn commit: r525698 - in /velocity/engine/trunk/src:
http://issues.apache.org/jira/browse/VELOCITY-533 On 4/23/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henning, Henning P. Schmiedehausen wrote: Christopher Schultz [EMAIL PROTECTED] writes: I'd be happy to attach this code to a Jira isssue in order to bless it as something being given away freely (but I reserve the right to publish it separately, since I will be releasing the evaluator sometime soon). Sure. It is your code. You do allow us to publish it under ASL if you check the feather button when you upload this. It is greatly appreciated! Okay. Is there an existing JIRA issue to which I can attach this? I went through this thread and couldn't find a reference to one. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLLJB9CaO5/Lv0PARAi7tAKCjQr2ECHadZ7hYHIFmZ/ht/d5BDQCfXKHf NAXtxQwwBd94rZSQ8CWm8z0= =GnrU -END PGP SIGNATURE- - 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: svn commit: r532551 [1/2] - /velocity/docs/src/docbook/userguide/VelocityUsersGuide.xml
Ah, it was in the next email. weird. On 4/25/07, Nathan Bubna [EMAIL PROTECTED] wrote: Why is there no diff for this? On 4/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: henning Date: Wed Apr 25 17:16:22 2007 New Revision: 532551 URL: http://svn.apache.org/viewvc?view=revrev=532551 Log: Update guide contents. Modified: velocity/docs/src/docbook/userguide/VelocityUsersGuide.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need a clarifcation about some issues
On 4/27/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, I have been playing with Velocity in the past few days. By doing so I encountered couple of problems. I'm not sure weather these are the documented behavior so I thought I should ask the list. 1.I couldn't set a property after I initialize the Velocity Engine (After calling the init() method). Here the particular property I was trying to set was MAX_NUMBER_LOOPS property. Correct. Properties must be set prior to initialization/use of the runtime. At this point, there is no support for changing properties in a runtime instance that's already in use. 2.I couldn't call inner class methods. I put an inner class object in to Velocity context and then tried to call its methods from the template. But it didn't work. Velocity just outputs the calling method name. Christopher is right here. Inner classes work just fine (i use them a lot), but they must be declared public just like any other classes you are trying access in a template. Thanks, Supun. - 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]
[veltools] status of 2.x branch
hey folks, so, i thought i'd give a heads up that VelocityTools 2.x has come along quickly. at this point, the new code can be used to build apps with much less configuration and much greater flexibility and power than the previous version. it is also almost completely backwards compatible. if you checkout and build the 2.x branch, you can run the simple and showcase examples with no changes and only two minor problems (having an issue with the IteratorTool and RenderTool demos). The VelocityStruts tools are not updated to work with the new system yet, but i should get to those soon. please feel free to check it out and give feedback. once i get 100% (or maybe 99.5%) backwards compatibility with the examples as they are, i will convert them to get rid of the deprecated config and such, in order to demonstrate the new configuration method(s). then we (probably i) can move on to bringing Veltag in (as VelocityViewTag) and perhaps creating a VelocityViewFilter and other such new possibilities. cheers, nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need a clarifcation about some issues
On 4/28/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: 2.I couldn't call inner class methods. I put an inner class object in to Velocity context and then tried to call its methods from the template. But it didn't work. Velocity just outputs the calling method name. Yes, this is AFAIK a known restriction. Can you open a JIRA issue for this so that it does not get lost? No, even VelocityTools uses inner classes extensively. If the class is public and the method is public, you should be good to go. It doesn't make any difference whether the class is inner or outer. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need a clarifcation about some issues
On 4/29/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi, My inner class was a private one. When I made it public everything worked well. Is it a issue that private inner classes are not working? (Henning suggested to open a Jira). No. Classes and methods that are private or protected should not be accessible within a template. No need to open an issue for this. Thanks, Supun. On 4/29/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 4/28/07, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Supun Kamburugamuva [EMAIL PROTECTED] writes: 2.I couldn't call inner class methods. I put an inner class object in to Velocity context and then tried to call its methods from the template. But it didn't work. Velocity just outputs the calling method name. Yes, this is AFAIK a known restriction. Can you open a JIRA issue for this so that it does not get lost? No, even VelocityTools uses inner classes extensively. If the class is public and the method is public, you should be good to go. It doesn't make any difference whether the class is inner or outer. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Remove Author tags?
On 5/3/07, Ahmed Mohombe [EMAIL PROTECTED] wrote: Basically removing all the @author tags from the velocity code base and docs and replacing it with 'Velocity development community' and a link to the dev-list. How about doing this? -1 from me as a user. In a lot of projects when I had problems, I was able to ask directly the author(s) of that class/utility, and this was very helpful. The complete project was too big and the work of just too many people. as an author who gets asked user questions off-list, you should know it's annoying to me. i would rather you write an email to the user list starting Nathan, you jerk! would you help, than ask for my time personally, without my invitation or an offer of pay from you. my response to personal user emails has for years included this link: http://www.catb.org/~esr/faqs/smart-questions.html#uselists and lately has also included the offer of personal consulting work for a fee. i volunteer on the lists. off-the-list, i now expect to be paid. Why don't you people concentrate on important things, e.g. like performance? because it's not a problem for me. If you want to pay me to pull out a profiler, look for bottlenecks, and widen them, then contact me personally. i'd be happy to consider that. Do you really think the users do care so much about cosmetics when the concurrent products/technologies get real improvements? did you notice that this was on the dev@ list? we're not talking about doing this for the users' sake. I'm just curious :), Ahmed. - 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: [VELTOOLS] StrutsLinkTag.setForward
On 5/8/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, Nathan Bubna wrote: I'm not sure. Have you tried it? Of course! ;) just didn't want to assume... :) It doesn't work :( StrutsLinkTool.setForward() basically just hands things off to StrutsUtils.getForwardURL(request, app, forward), which says it Returns the action forward name converted into a server-relative URI reference and doesn't mention the word global. StrutsLinkTool.setForward does say global while StrutsUtils.getForwardURL does not. However, a quick look at the code shows that there's no attempt to deal with the currently-running ActionConfig: ModuleConfig moduleConfig = ModuleUtils.getInstance().getModuleConfig(request, app); ForwardConfig fc = moduleConfig.findForwardConfig(forward); // massage the String a bit and return I'm not sure how it would affect any other code, but it would be nice to add/change-it-to something like this: ActionConfig actionConfig = request.getAttribute(Globals.MAPPING_KEY); ForwardConfig fc = actionConfig.findForward(forward); // massage and return ActionConfig.findForward returns either a local forward or a global forward if no matching local is found (or null is nothing is found at all). I would imagine that the ActionConfig would already know about its enclosing ModuleConfig so I think it can be a straight replacement. sounds sensible. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQKdZ9CaO5/Lv0PARAsxFAJ9XeSNrBMa0tfRfx0iOcwtYuiZ8VwCeOInh MVmh/8Hloz1oWVoiu/5zQKc= =H3lX -END PGP SIGNATURE- - 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: [veltools] status of 2.x branch
On 5/16/07, Claude Brisson [EMAIL PROTECTED] wrote: Le mercredi 16 mai 2007 à 15:41 -0700, Nathan Bubna a écrit : i don't know if anyone else has taken the time to try out Tools 2.x or cares about it yet, but i thought i'd give an update anyway... For now I just followed your updates. I'll try them soon (as soon as I'll end up fighting with maven 2...). I am positively impressed by your work, btw. thanks :) [...] As this is a significant milestone, i thought i'd ask if anyone is interested in having an alpha release or milestone build. I'd love to get some feedback on the progress so far, as well as the backwards compatibility of things. Would that help lower the barrier for some of you to try it out? I just tried a drop-in replacement, just to see what would happen. It failed in my case due to the fact that the ViewTool interface disappeared - after all the efforts you made to reach BC we should probably put it back, as deprecated... hmm. it's already deprecated and useless as of the 1.3 release. it should be trivial to remove reference to it. that's all you need to do... I'm too drunk tonight (an official site release at work...) to commit anything but after having added it back, I got : [01:42:42.321] Velocity [debug] Loading configuration from: /WEB-INF/toolbox.xml [01:42:42.364] Velocity [trace] Searching for configuration at: /WEB-INF/tools.xml [01:42:42.366] Velocity [debug] Could not find file at: /WEB-INF/tools.xml (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?) no. newer should override older. since a tools.xml should always be the newest configuration file, it should have the opportunity to override any tool/toolbox/data definitions configured in the old toolbox.xml. [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm (I don't use any struts, only jar.view... where does this reference to struts come from?) ah, this is interesting. i'm guessing you were actually using the full velocity-tools jar, not just the velocity-tools-view jar. if you are sure you were using the velocity-tools-view jar, then i'll have to try it myself. this shouldn't have happened for that. anyway, assuming my guess is correct, here's the explanation: since VelocityView will now load all available tools by default, it is trying to load the VelocityStruts tools. during the load process, we still create an instance to be sure (as early as possible) that we are able to do so. so, when it tries to create a struts tool instance, the VM is trying to load all the classes that tool needs. since you don't have the struts dependencies on the classpath, that fails. i'll have to think of a way to fail more gracefully (or perhaps just log an error) when this happens. in the meantime, you can add an init param to your VVS declaration in your web.xml with the name: org.apache.velocity.tools.suppressDefaults and the value of: true that will let you get past this error and continue testing... [01:42:42.498] at java.lang.Class.getDeclaredMethods0(Native Method) [01:42:42.498] at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [01:42:42.498] at java.lang.Class.getMethod0(Class.java:2670) [01:42:42.498] at java.lang.Class.getMethod(Class.java:1603) [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.isOldTool(ToolConfiguration.java:134) [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.toString(ToolConfiguration.java:205) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106) [01:42:42.498] at org.apache.velocity.tools.config.ToolboxConfiguration.toString(ToolboxConfiguration.java:154) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106) [01:42:42.498] at org.apache.velocity.tools.config.FactoryConfiguration.toString(FactoryConfiguration.java:130) [01:42:42.498] at java.lang.String.valueOf(String.java:2827) [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:496) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:356) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:291) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:189) [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:181) [01:42:42.498] at org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:80) [01
Re: [veltools] status of 2.x branch
On 5/16/07, Claude Brisson [EMAIL PROTECTED] wrote: Le mercredi 16 mai 2007 à 17:24 -0700, Nathan Bubna a écrit : I just tried a drop-in replacement, just to see what would happen. It failed in my case due to the fact that the ViewTool interface disappeared - after all the efforts you made to reach BC we should probably put it back, as deprecated... hmm. it's already deprecated and useless as of the 1.3 release. it should be trivial to remove reference to it. that's all you need to do... Yes - and I knew it... some old tool lying around... (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?) no. newer should override older. since a tools.xml should always be the newest configuration file, it should have the opportunity to override any tool/toolbox/data definitions configured in the old toolbox.xml. Ah. If overriding comes into play, it is of course the right order... [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm (I don't use any struts, only jar.view... where does this reference to struts come from?) ah, this is interesting. i'm guessing you were actually using the full velocity-tools jar, not just the velocity-tools-view jar. if you are sure you were using the velocity-tools-view jar, then i'll have to try it myself. this shouldn't have happened for that. Your guess was correct. I used 'jar' instead of 'jar.view' by inadvertence, and since jar == jar.struts... thought so. anyway, assuming my guess is correct, here's the explanation: since VelocityView will now load all available tools by default, it is trying to load the VelocityStruts tools. during the load process, we still create an instance to be sure (as early as possible) that we are able to do so. so, when it tries to create a struts tool instance, the VM is trying to load all the classes that tool needs. since you don't have the struts dependencies on the classpath, that fails. this isn't quite right. i didn't look closely at the stack trace you sent. turns out, this is happening when just trying to look for an init() method in the tool. no new instance is being created yet. worse still, the error happens during a call to ToolConfiguration.toString(). that's definitely not ok. first i'm going to clean that up... i'll have to think of a way to fail more gracefully (or perhaps just log an error) when this happens. Yes, logging an error with its stacktrace looks enough to me. then i'll look into ways to shush errors when loading default tools... in the meantime, you can add an init param to your VVS declaration in your web.xml with the name: org.apache.velocity.tools.suppressDefaults and the value of: true that will let you get past this error and continue testing... or using the right jar... I really like the trace of the scoped tools in the log, BTW. On the next test I made, I ran into the first real problem, I think: the init(Object) method seems to not be called at all on an old request tool. If you've got an idea about this symptome, well tant mieux (don't know the english equivalent...), otherwise I'll investigate - it will make me more familiar with the new codebase :-) does the log description of the toolboxes say whether the tool in question is Old or not? i thought i had this case supported, but i could be wrong. i haven't tested it much yet. Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] status of 2.x branch
On 5/16/07, Claude Brisson [EMAIL PROTECTED] wrote: Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit : On the next test I made, I ran into the first real problem, I think: the init(Object) method seems to not be called at all on an old request tool. If you've got an idea about this symptome, well tant mieux (don't know the english equivalent...), otherwise I'll investigate - it will make me more familiar with the new codebase :-) does the log description of the toolboxes say whether the tool in question is Old or not? Yes, old (which -just guessing, correct me if I'm wrong- is synonym to the fact that it has a void init(Object data) method, the one we'd like to see called). yeah, it means that we need to support init(Object). tools should be treated as old if they have an init(Object) method that is NOT deprecated. i'm glad it at least identified the tool as old correctly. now to make sure that init() gets called... i thought i had this case supported, but i could be wrong. i haven't tested it much yet. Somehow reassuring to see you leave a few bugs sometimes... heh. Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] status of 2.x branch
Ok, the problem with init() not being called is fixed. also, i changed VelocityView to not load the default tool configs when an old toolbox.xml is in use. this means that people using the old toolbox.xml can drop in the full jar (including VelocityStruts) and not have configuration exceptions thrown at them. as things stand, however, once they move to a tools.xml or tools.properties configuration and/or add the org.apache.velocity.tools.loadDefaults=true property to their web.xml init params, they will get a exception on startup if they are using the full VelocityStruts jar but do not have the Struts dependencies on the classpath. i did this for now, because it's easier. simply logging an error message when dependencies are missing (as opposed to throwing an exception) will actually be pretty difficult to pull off as things are currently organized. i'll continue to think about ways to do that or make it optional, but it's looking like quite the challenge at the moment. On 5/16/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 5/16/07, Claude Brisson [EMAIL PROTECTED] wrote: Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit : On the next test I made, I ran into the first real problem, I think: the init(Object) method seems to not be called at all on an old request tool. If you've got an idea about this symptome, well tant mieux (don't know the english equivalent...), otherwise I'll investigate - it will make me more familiar with the new codebase :-) does the log description of the toolboxes say whether the tool in question is Old or not? Yes, old (which -just guessing, correct me if I'm wrong- is synonym to the fact that it has a void init(Object data) method, the one we'd like to see called). yeah, it means that we need to support init(Object). tools should be treated as old if they have an init(Object) method that is NOT deprecated. i'm glad it at least identified the tool as old correctly. now to make sure that init() gets called... i thought i had this case supported, but i could be wrong. i haven't tested it much yet. Somehow reassuring to see you leave a few bugs sometimes... heh. Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VELTOOLS2] access to some VelocityView methods
Sure, go for it! On 5/28/07, Claude Brisson [EMAIL PROTECTED] wrote: I propose to relax the access to the three following methods in VelocityView.java : -protected Template getTemplate(HttpServletRequest request) +public Template getTemplate(HttpServletRequest request) -protected Template getTemplate(HttpServletRequest request, HttpServletResponse response) +public Template getTemplate(HttpServletRequest request, HttpServletResponse response) -protected void merge(Template template, Context context, Writer writer) +public void merge(Template template, Context context, Writer writer) The purpose is to let subclasses of VelocityViewServlet be able to call them. A typical use case (for the last one) is to be able to use an alternate writer while still calling getVelocityView().merge(...). Nathan, are you +1 on this? Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macros - max recursion depth
On 6/1/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, Nathan Bubna wrote: 2. Throw another exception (MacroDepthExceededException?) The way I see it, neither of these options is any better than simply allowing the stack overflow to occur. Stack overflows can be caused by many things. Throwing a MacroDepthException is much more informative, and in the case of 3rd party templates being introduced to a running system, can prevent DOS type stuff. Yeah... as I was typing that question, I was thinking well, stack overflow could mean many things, although I immediately assume that my template has infinite recursion in these cases ;) :) I hasn't really thought about 3rd-party templates. Does anyone have any data on the impact of a stack overflow on a running app server? I would imagine that a better way to perform a DOS would be to concatenate strings forever in an endless loop. There's really no checking that can be done against that. still plugging what holes we can ain't a bad thing :) Okay. Enough nay-saying from me ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYGY39CaO5/Lv0PARAm9iAJ0cYAW0Rs6h5yfVwefQkvPcMnUmPgCgjnkV IG5pXk8OVJY+44SHv+mr/i0= =9F0i -END PGP SIGNATURE- - 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: [anakia] discussion of recent refactoring
On 6/1/07, Matt Benson [EMAIL PROTECTED] wrote: --- Nathan Bubna [EMAIL PROTECTED] wrote: On 6/1/07, Matt Benson [EMAIL PROTECTED] wrote: Hi--you will find me to be a complete novice to Velocity and Anakia; nevertheless I have come to spoil the fun. ;) Actually I feel like my timing is pretty good as I have come to talk about further changes to the recent Anakia refactorings: I say my timing is good because it appears the changes to which I refer were made post-1.0 and therefore further refactoring will not result in backward compatibility issues (please advise if I am mistaken about this). not quite sure what you mean. it's hard to tell if further refactoring will cause BC issues without know what the refactoring involves. in any case, we could always do an Anakia 2.0, if the further refactoring was sufficient to warrant it. My thought process was that Anakia as a standalone class has not yet been released into the wild, so no matter what is done to it there are no BC issues. An Ant 1.7-compatible Anakia task would probably indicate Anakia v2.0. Gotcha. Yes, Anakia as a standalone class is unreleased and thus very open to change. I'll take this brief moment to--possibly unnecessarily--introduce myself (I think several of the key Velocity players are familiar to me from the jakarta and commons dev lists). I am a Jakarta (commons) committer as well as a member of the Ant PMC. I have begun looking into Anakia recently and with my Ant hat on I'd like to make some suggestions. I would provide my suggestions in the form of patches but I'm unfortunately not yet clueful enough wrt to Anakia/Velocity codebases. we can help there. anything in particular you'd like to know? I see. You're gonna go smart questions on me. ;) i've been known to do such things.. ;) With all that out of the way, to the one or two or you who may still be paying attention: I'm sure it should surprise no one for me to accuse the AnakiaTask of being very old-school Ant; it predates my use of Ant (let alone my actual involvement). For BC reasons, at least for now, that's fine; however, with the Anakia class having been recently extracted from the AnakiaTask, I see no reason whatsoever that the Anakia processor itself cannot be written in a more abstract way. In particular I'd like to discuss the idea of reusing Velocity's Resource (and related) concept(s) here, giving the Ant task more responsibilty with regard to providing Ant (small 'r') resources in terms of Velocity Resources. This would allow the AnakiaTask v1.x to remain compatible with Ant 1.6 (possibly/probably earlier versions but that's the version in the POM), while allowing other clients of the Anakia processor to be more agile, particularly by permitting the use of non-file resources. A directly related issue is that Ant 1.7.0 and beyond greatly extend Ant's own Resource concept such that adapters from Ant Resources to Velocity Resources, and related other adapters, should be fairly trivial to write: a 1.7-specific AnakiaTask could be quite an advance over the current implementation in terms of capability. not that Anakia or Ant are my fortes, but this sounds like a good way to go. Glad to hear it. My initial investigation into the Anakia/Velocity code indicates that there may be some Velocity-specific idiosyncrasies with regard to ResourceLoader configuration, etc., so I have as yet been unable to determine the correct steps to take in modifying the Anakia processor class to use Resources. I present my case here hoping for some direction from experienced Velocity developers. sure. got any specific questions here? or are you looking for a general primer on Velocity ResourceLoaders? Sort of the latter, yes. There simply seems to be a lot of magic involved; I've seen implications that only one e.g. file ResourceLoader can be active for a VelocityEngine, and similar things that strike me funny. You can definitely have as many FileResourceLoaders as you want, either per engine or per app, you just can't name them all file. Try file2 or otherfile for latter ones. :) However, i don't know of many usecases for having multiple FileResourceLoaders. Most often you find people mixing different resource loader impls. Such as a FileResourceLoader and a ClasspathResourceLoader. or a WebappLoader (from VelocityTools) and a DataSourceResourceLoader. The StringResourceLoader has some pretty serious flaws in Velocity 1.5, so you can currently only use one per JVM. This has been fixed for Velocity 1.6, though. If there is a current Resource guru in Velocity-land who could provide an overview, that would certainly be welcome. Quick looks at the ResourceManagerImpl didn't leave me with a strong impression of what level of customization is intended to be supported. I dunno if there's
Re: [anakia] discussion of recent refactoring
On 6/3/07, Matt Benson [EMAIL PROTECTED] wrote: --- Nathan Bubna [EMAIL PROTECTED] wrote: snip/ The last thing that might be handy to know is that you can also feed an already instantiated ResourceLoader into the system (rather than have it be loaded and instantiated by class name). If you want more details on that, ask away. :) This is the most interesting thing to me--it seems like a reasonable assertion to say that other APIs intending to use Velocity under the covers would be justified in doing things in as much a Java-centric, and consequently as little a Velocity-centric way, and being able to easily set up the ResourceLoader without having to rely too much on Velocity's internal machinery would seem to significantly decrease the ramp-up time to productivity. IOW, I would definitely like to know more about this subject. :) ok, i haven't used this myself; i've only noticed it in the code. so, this may be trickier than it seems. but here's what i see... create or instantiate your ResourceLoader subclass... ResourceLoader fooLoader = new FooResourceLoader(); get a handle for the Properties file you'll be using to call velocityEngine.init(properties) with. then, *before* you call velocityEngine.init(properties) do: properties.setProperty(resource.loader, foo); properties.put(foo.resource.loader.instance, fooLoader); then you can call velocityEngine.init(properties); the ResourceManagerImpl should then find your ready-to-go resource loader instance and use that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: echo messages from Sergio Reais
Me too. And it's worse than that. A couple of Sergio's emails have been empty replys to his own replys to a commit message. Who's the moderator for our lists anyway? Can we shut these down? On 6/8/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/8/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Is anyone else getting an echo (empty reply) for every commit message from Serio Reais? Yes. Niall What's up with that? WILL - 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: how to use I18N in macros
This is a question for the Struts2 user list. They are the ones who created and maintain the #ssubmit directive. You may get an answer here, but it is not likely. I'm not aware of any Struts2 users or developers who are active on this list. On 6/25/07, sudhitekkala [EMAIL PROTECTED] wrote: hello to develop a page in velocity i am not getting the design as expected ... so i started using macros so that i can get the expected design for example::: table tr td#ssubmit(key=button1 value=Search)/td td#ssubmit(key=button2 value=Submit)/td /tr /table i have taken the key attribute for the purpose of i18n...actually it should work as in one row to td's should form in which each should hold two submit buttons... but when you observe the html page the second submit button will be taken as in second row... in this case i used macro to get the two submit buttons in the one row as bellow::: #macro(button $value) input type=submit value=$value #end table tr td#button(Search)/td td#button(Submit)/td /tr /table here i am getting the design but when i am writing the key attribute in the macro or in the calling macro i am not at all seeing the button in the html page if possible please kindly solve my problem regards -- View this message in context: http://www.nabble.com/how-to-use-I18N-in-macros-tf3975258.html#a11284160 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: web site question: tag vs branch.
we need to find some way to get a Wendy Smoak-type person interested in helping out around here. she has far more expertise and patience for build and doc issues than i could ever dream of having... :) anyway, here's my thoughts: - whoever's ready and willing to jump in and do work on the site building/doc stuff will pretty much always get my support for whatever they want to do with it. let them who do the work make the decisions. :) so, +1 to anyone willing to step up and execute their plan to solve this. - that said, don't we have two sections on the site for each project? the little fixes and stuff should always go in the development docs for the project, and these should be based of the trunk or a branch. once there has been a new release, then we tag that release and update the release docs using that tag. if, in the meantime, the X.x release docs online for some project are broken, then c'est la vie. those were the docs for the release. - i'm not keen on the idea of separating the docs from the release cycle. i'd rather see us consider doc upgrades and fixes as worthy of an X.x.x release. - to reiterate: the last two points are my opinions at the moment. i'll happily follow the lead of someone actually doing the work, even if they go a different way. On 6/27/07, Claude Brisson [EMAIL PROTECTED] wrote: For now, the scripts on velocity.zones use tags (as stated by svn info in /export/home/velocity/deploy/releases/velocity-texen-1.0-site), but I wonder if it is the proper choice, since tags are not supposed to evolve... it'd be quite heavy to have to create a new tag each time we correct a bad link. The way to go would IMO to link online sites to branches, since online sites can be newer than docs included in the last released version. Also, sticking to tags would mean having to issue an svn switch for each fix we've got to put online. I can setup this (by svn-switching checkouts) if you consider it appropriate. Claude Le dimanche 24 juin 2007 à 06:51 -0700, Will Glass-Husain a écrit : Hi, I'm fixing the home page for Texen. (bad links). Quick question on website/svn process, probably for Henning our site guru. I'm updating both texen/trunk and texen/branches/Texen-1.0. When we rebuild the website, for the 1.0 tree does it use the tag or the branch? In other words, will the fix show up automatically, or do we need to release 1.0.1 for this to happen? WILL - 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]
[VOTE] Release VelocityTools 2.0-alpha1
VelocityTools 2.0 is, in my estimation, ready for an alpha release. I would call this a beta, but it has essentially no updated documentation and has received precious little feedback to date. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/ Check out the release artifacts, play with an example, and vote! :) [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 10am PST on Saturday, Feb 24th. If there aren't enough +1s and no -1s, then the vote will stay open until either i'm tired of waiting or all PMC members have voted. :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 2.0-alpha1
On 6/27/07, Nathan Bubna [EMAIL PROTECTED] wrote: VelocityTools 2.0 is, in my estimation, ready for an alpha release. I would call this a beta, but it has essentially no updated documentation and has received precious little feedback to date. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/ Check out the release artifacts, play with an example, and vote! :) [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 10am PST on Saturday, Feb 24th. If there aren't enough +1s and no -1s, then the vote will stay open until either i'm tired of waiting or all PMC members have voted. :) By the way, that close date should have been updated to roughly 4pm PST on Saturday, June 30th. Oops. :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 2.0-alpha1
If you need the extra hour, then you are welcome to it. :) On 6/28/07, Will Glass-Husain [EMAIL PROTECTED] wrote: PST or PDT? Nice bonus to get that extra hour :-) :-) On 6/28/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 6/27/07, Nathan Bubna [EMAIL PROTECTED] wrote: VelocityTools 2.0 is, in my estimation, ready for an alpha release. I would call this a beta, but it has essentially no updated documentation and has received precious little feedback to date. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/ Check out the release artifacts, play with an example, and vote! :) [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 10am PST on Saturday, Feb 24th. If there aren't enough +1s and no -1s, then the vote will stay open until either i'm tired of waiting or all PMC members have voted. :) By the way, that close date should have been updated to roughly 4pm PST on Saturday, June 30th. Oops. :) My vote is +1 - 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: [VOTE] Release VelocityTools 2.0-alpha1
Turns out the test directory was being left out of the source zips, both in 2.x and 1.x. I'll re-post the vote for 2.0-alpha1 promptly... On 6/28/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi -1. ant test fails for me. Or is there something I'm doing wrong? I'm running JDK 1.5 and ant 1.7. (confirmed with ant env and ant -version). * downloaded velocity-tools-2.0-alpha1-src.zip * unzip and cd to main directory * ant clean * ant test test.generic: prepare.test: [mkdir] Created dir: C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity-tools-2.0-alpha1-src\buil d\test\rst [mkdir] Created dir: C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity-tools-2.0-alpha1-src\buil d\test\classes [mkdir] Created dir: C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity-tools-2.0-alpha1-src\buil d\test\log [copy] Copying 7 files to C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity-tools-2.0-alpha1-sr c\build\test\src BUILD FAILED C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity- tools-2.0-alpha1-src\build.xml:599: The following error occurred while executing this line: C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity- tools-2.0-alpha1-src\test.xml:75: Warning: Could n ot find file C:\Documents and Settings\wglass\My Documents\Workspace\misc\velocity-tools-2.0-alpha1-src\test\etc\jetty.x ml.tmpl to copy. WILL On 6/28/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 6/27/07, Nathan Bubna [EMAIL PROTECTED] wrote: VelocityTools 2.0 is, in my estimation, ready for an alpha release. I would call this a beta, but it has essentially no updated documentation and has received precious little feedback to date. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/ Check out the release artifacts, play with an example, and vote! :) [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 10am PST on Saturday, Feb 24th. If there aren't enough +1s and no -1s, then the vote will stay open until either i'm tired of waiting or all PMC members have voted. :) By the way, that close date should have been updated to roughly 4pm PST on Saturday, June 30th. Oops. :) My vote is +1 - 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: [VOTE] Release VelocityTools 2.0-alpha1
On 6/29/07, Ahmed Mohombe [EMAIL PROTECTED] wrote: Nathan Bubna-3 wrote: VelocityTools 2.0 is, in my estimation, ready for an alpha release. I Why not user the same version number like Velocity? never done it before. all Tools 1.x releases are (i believe compatible with all 1.3+ Engine releases). This way it would be much simpler for the users to match versions. E.g. they would intuitively use Velcity 1.6 with VelocityTools 1.6. it would be cool if that just happened. for Tools 1.1, 1.2, 1.3, we were relatively lucky to have the Tools version numbers line up to the Struts 1.x version numbers, but that was 90% coincidence. i don't, however, think it is worth it to alter development pace (rushing or holding back on release cycles) just to keep numbers in sync. better to just document what version(s) of Velocity are required for each version of VelocityTools. Tools 2.0, while it is highly compatible with 1.x versions, is largely a rewrite of the internal infrastructure and involves a lot of package shuffling and refactoring. what compatibility there is comes through a huge number of deprecated classes and methods put/left in place just for that purpose. Those will start disappearing in subsequent version minor version releases. Calling this a 1.x release would be quite a stretch. Ahmed. -- View this message in context: http://www.nabble.com/-VOTE--Release-VelocityTools-2.0-alpha1-tf3991455.html#a11361412 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 2.0-alpha1 (Take 2)
On 6/29/07, Claude Brisson [EMAIL PROTECTED] wrote: I tested it in a real webapp and it seems ok... The new api is really much cleaner than the 1.x, that's a pleasure to use it! good to hear! There are some small developments I'd like to commit in but they are not ready and will wait for the 2.1 release. we're only in alpha stage right now. unless they're really drastic, i think they should go in now. To me, alpha means the big refactorings and core infrastructure is done; here's something to *start* working with. expect some changes. I'm likely to make more than a few small developments too. so, +1 One remark: when fully rebuilding I saw that there remains some internal references to deprecated classes, like to the old ToolInfo class in o.a.v.tools.view package, that could easily be changed. it's something we need to consider. at this point, i've decided to leave the old core infrastructure in place and deprecated. i know there's not likely to be many people who directly interacted with it (and thus we probably can yank it), but it's not really hurting anything and might still be useful in some way i haven't foreseen. also, i have occasionally thought that it might be nice to break the many deprecated class out into a separate backwards compatible build, but then we're basically talking about doubling the number of jars we distribute. since we already put out three, that seemed like overkill. anyway, all that is to say, we should have a discussion at some point about whether and/or how long we want to leave the various deprecated pieces (support for old toolbox format, support for Tools with init() methods, and the old tool management infrastructure) in place. Claude Le vendredi 29 juin 2007 à 09:36 -0700, Will Glass-Husain a écrit : Ok, I change my vote to a +1. Don't want to hold up progress here. After all, it's an alpha. Anyone who uses this and complains about missing docs will get support on the list. does this really matter for an *alpha*, especially when none of the docs have been updated and so many of them are wrong, and the tools are mostly documented via javascript? Best, WILL On 6/29/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 6/28/07, Will Glass-Husain [EMAIL PROTECTED] wrote: -1. (sorry!) There are no docs. All the generated doc files in the binary distro have size of 0KB. In the source distro, typing ant docs also produces bad docs. does this really matter for an *alpha*, especially when none of the docs have been updated and so many of them are wrong, and the tools are mostly documented via javascript? Again, let me know if I'm missing something obvious. On the positive side, ant test worked fine under both JDK 1.5 and JDK 1.6 I'll note some trivial nits, probably want to fix before final 2.0release -- notice file has 2006 copyright, not 2007 will fix. -- ant clean doesn't remove empty target directory that's mvn/ant crossover. will fix, but doesn't matter. -- the VLS_readme file is written in the first person tense, but who is that person? (no one signed the message) been that way for all final releases. i wrote it before i was even a committer, i believe. -- the STATUS file appears to be out of date. (not sure-- worth a check). it's an alpha. all the docs are out of date. :) best, WILL On 6/28/07, Nathan Bubna [EMAIL PROTECTED] wrote: Ok, here goes again. The problem with the source build has been fixed and my refactorings from this morning are now included. Sorry that we have to do this again, but here goes: The new test build for this release is once again available at: http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/ Check out the release artifacts, play with an example, and vote! :) [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, but i won't wrap it up until the morning of Monday, July 2 at the earliest. If there aren't enough +1s and no -1s, then the vote will stay open until either i'm tired of waiting or all PMC members have voted. :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
[RESULT] [VOTE] Release VelocityTools 2.0-alpha1 (Take 2)
The vote has passed: +1 Nathan Bubna, Will Glass-Husain, Claude Brisson No other votes were recorded. On 6/28/07, Nathan Bubna [EMAIL PROTECTED] wrote: Ok, here goes again. The problem with the source build has been fixed and my refactorings from this morning are now included. Sorry that we have to do this again, but here goes: The new test build for this release is once again available at: http://people.apache.org/~nbubna/velocity/tools/2.0-alpha1/ Check out the release artifacts, play with an example, and vote! :) [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, but i won't wrap it up until the morning of Monday, July 2 at the earliest. If there aren't enough +1s and no -1s, then the vote will stay open until either i'm tired of waiting or all PMC members have voted. :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release DVSL 1.0 (bis)
-1 :( sorry... It was built with Java 6, while it should probably be built with as early of a JDK as possible. Due to some uses of the @Deprecated annotation, i believe this is Java 5. Though perhaps, we can have the compiler target 1.4? I really wouldn't be picky about this if it were an alpha or beta, but for a final release, we should make this as widely useable as we can. On 7/7/07, Claude Brisson [EMAIL PROTECTED] wrote: Here we go again. This time with a proper pre-release process (thanks a lot for explanations!). Shall we relase DVSL 1.0 ? The release files are available at http://people.apache.org/~cbrisson/velocity/dvsl/1.0/ [ ] +1 Let's do it. [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ +1 for me Claude - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including macros using #parse
On 7/26/07, Jonathan Revusky [EMAIL PROTECTED] wrote:
Nathan Bubna wrote:
I believe your analysis is correct. The parser will have to treat
anything in the form of #foo( ... ) is a potential macro at parse
time, then leave the check for a matching macro to render time. If it
turns out to be a macro, then we should render the macro, if not (and
this may turn out to be tricky), we need to render that text exactly
as it was, whitespace and all.
Out of idle curiosity, how often do you think that a template writer
actually wants to output something like #foo($bar, $baz) to the output?
In the cases where you do see that there is no #foo macro in the
context, would this not be, in the overwhelming majority of cases, a
result of some kind of coding error?
Agreed, it would be good to log a warning (perhaps error?) level
message about it as well.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
On 7/18/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote:
Hi,
I was looking into the issue of including macros via the #parse
method. Following is the my understanding of the problem. The main
reason that causes this to be a hard problem to solve without touching
the parser implementation is described below.
At the moment when the parser encounter a call to a macro i.e.
#foo(123) it looks weather a macro definition exists via the runtime
system. If a definition exists everything is going well. This happens
in the AST building face of the parser (not in the rendering face). So
this means with the current implementation, the macros must be
registered with the runtime system before a call occurs and this is
the cause of all the troubles.
Now this is the problem with #parse directive. #parse directive builds
the AST of the files and render them at the same time. This happens
when the main template that include the #parse directive get rendered.
But when this happens, AST of the template that include the #parse
directive is been built already. But the macro calls that are in the
main template get invalidated because at the moment AST is built
macros are not registered with the runtime system.
As I can see the solution for this problem is, parser should not look
into the runtime system to determine weather a directive like #foo()
is a macro call or not. Instead parser should look ahead for the '('
token when it encounters something like #foo to deside weather it is
a macro call or not.
I would like to know weather this is solvable without breaking the
current system in the way that I have decribed above?
Regards,
Supun.
P.S. If we can do this my first implementation of 'including macros
programmatically' can be done using this method.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Template.merge() doesn't throw ParseErrorException
On 8/1/07, Nicholas Beckett [EMAIL PROTECTED] wrote:
Hi,
I'm testing an application that uses the Velocity Template engine. I've
deliberately introduced some parse errors in to my .vm file to test
error handling in Template.merge(). The error is a $variable that isn't
present in the context.
According to the API this should cause merge() to throw a
ParseErrorException, but it doesn't. I do get a log in velocity.log, but
no exception is thrown.
Where did you read that a ParseErrorException would or should be
thrown if a $variable isn't present in the context? That's never been
standard. To get a missing reference to throw an exception, you would
need to configure a special event handler to do that.
I know Velocity bug 467 is tracking a similar issue (Velocity should
throw more Exceptions), but this case seems a little different, in so
much as the merge() method doesn't match the published API.
Has anyone else seen this? Can anyone suggest an alternative way of
detecting parse errors from within the application?
I believe you are looking for something like this:
http://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/app/event/implement/ReportInvalidReferences.html
Thanks,
Nicholas
Code extract:
try
{
lTemplate = Velocity.getTemplate(lTemplateName);
lTemplate.merge(xiContext, lWriter);
}
catch(ParseErrorException e)
{
throw new TemplateException(e.getMessage(),
Failed to parse template for +
xiTemplateType,
lTemplateName);
}
.vm file extract:
#set($Variable=$imnothere.notamethod())\r\n
$Variable things to do\r\n
velocity.log extract:
41:57,352 - RHS of #set statement is null. Context will not be modified.
snstemplates/fax-urgent-body-en_US.vm [line 5, column 1]
2007-07-27 14:41:57,352 - Null reference [template
'snstemplates/fax-urgent-body-en_US.vm', line 6, column 1] : $Variable
cannot be resolved.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table creation helper package for Velocity?
On 8/7/07, Christopher Schultz [EMAIL PROTECTED] wrote: Nathan, Nathan Bubna wrote: I also wonder if there's some way to turn your Table/Cell classes into a TableTool of sorts that could go into the VelocityTools project. http://velocity.apache.org/tools/devel/ While I think this is an interesting tool, I don't think it's widely applicable enough to go into the VelocityTools project. Most of the tools already provided are useul in a very wide range of applications, but this one seems very narrow. Organizing data into tables is pretty common. things like DisplayTag are quite popular in the JSP world (actually displaytag is 80% of why i like to see Velocity and JSP play together better). While it would probably take a herculean effort to turn this into a match for that anytime soon, having something to simplify the process of outputting tables of data would be a small step in that direction. i'm not saying that i'm sure this would fit in VelocityTools, but i'm think it might with a little work. i'd at least like to see more of it. I like your idea of putting it onto the Contributed Code section of the Wiki, though. Just my two cents always appreciated!! -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Velocity Support JSF components to be integrated with it along with Seam Framework and EJB 3.0?
On 8/21/07, B.Rajagopal [EMAIL PROTECTED] wrote: Hello, Now I am in the possition to choose the good presenation layer frame work to start working the web oriented project. I have been looking around the forum to use the velocity. We have decided to use the new technologies like Seam Framework, EJB3.0 and JSF with MyFacelets. But MyFaclets has some issue to format the view layer, It does not have the good tag library as like jstl. We have thinking to use the velocity for presentation layer. I would like to know whether the Velocity support JSF ,EJB3.0 with Seam Framework ? the Velocity project has not done any work to specifically integrate with JSF or EJB or Seam. How the taglib support with Velocity ?. if you are asking about calling taglibs from within a Velocity template, then the support is very poor. the WebWork guys did some such integration a long time back, but i don't know the status of it. It's not something there's been much demand for. Instead most work has gone into the VelocityTools project (tools been a Velocity corollary to taglibs). I would appreciate the If Anyone help me on getting clear idea about Velocity ... thanks -- View this message in context: http://www.nabble.com/Does-Velocity-Support-JSF-components-to-be-integrated-with-it-along-with-Seam-Framework-and-EJB-3.0--tf4305083.html#a12254295 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VELOCITY-362 and VELOCITY-529 Solved
Great work, Supun! The code and tests look great. I look forward to trying this out myself. On 8/22/07, Supun Kamburugamuva [EMAIL PROTECTED] wrote: Hi list, I'm really glad that I could solve both VELOCITY-362 and VELOCITY-529. Here is a general description about how I solved the two problems. These two problems are interrelated and solving one gives the chance to solve the other as well. For example if we can specify that a set of macro files must be used for a particular rendering of a template (VELOCITY-529) that same underlying mechanism can be used for specifying that #parse files must be used for the rendering of a template. As I have mentioned previously in a mail, the problem with the #parse and macros was that parse files are built (building AST) and rendered at the render time of the template. Macro call is considered valid if it already has an implementation (it has to be registered). So the problem was that macros are defined in #parse files which are built after the files which contain the macro calls were built. So the macro calls got invalidated and considered as text. In my approach I don't invalidate macros at the parsing time and let that happen at the render time. So a macro call without a macro implementation won't get invalidated. I have done few changes to the parser to support this. When we see a macro call instead of requesting for a VelocimacroProxy object I'm creating a RuntimeMacro object. I have added few methods to the InternalHouseKeepingContext to hold the macro libraries associated with a particular merge. When a template.merge happens with a macro libraries list the macro libraries (names) are added to the context. When the RuntimeMacro is rendered it checks for a Macro implementation in the Macrolibraries specified in the context. If it can find a VelocimacroProxy it initializes it and then renders it. VELOCITY-529 Template.merge(context, writer, Macro Library List); VELOCITY-529 #parse(macroLibrary.vm) ##use macros from the library #foo() I think this mail is getting too long. I have added couple of test cases as well. Regards, Supun. - 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]
