I don't think Velocity has reached EOL just yet - there has recently been quite a bit of discussion on the Velocity dev list regarding recommencing active development and integrating several user patches.
Well, I am not the most objective source of information on this topic, as anybody can see from my sig. But the extremely neglected state of the Velocity project is really an objective fact. To all intents and purposes, nobody has committed any code for a year. You can see that from examining the archives of the velocity-dev list. Their last release, 1.3.1 final was in March, but that is deceptive, since 1.3.1 final was identical to 1.3.1rc2, and was AFAICS put out for marketing reasons, to give the impression that something was happening.
Believe me, Velocity, as a project, is in a very neglected state. For example, the user patches that they are discussing in the "recommencing" thread, the map support and decimal number support, were submitted last autumn. Like 8 months ago! That's really not very confidence-inspiring for anybody who will be in a position of relying on Velocity.
As for whether they are going to get moving again, for the moment that is all talk. I think that once development has stalled for that long, it's easier said than done. You know, if I don't work on code for a year, I forget my way around. It becomes very difficult to get back in. Right now, I know the FM codebase like the back of my hand, but if I didn't do anything there for a year or more...
BUT, I know that if Turbine DID support other template dialects, I would probably at least give FreeMarker a try, since it has some nice features that Velocity doesn't, like the including of templates in a location other than the template base directory, the compress directive, etc (from a quick look at the manual). If I discovered I liked Velocity better after spending some time with fm, I would switch back. It's the fact that Turbine doesn't support fm and other template dialects that prohibits me from trying alternative solutions.
It seems to me that offering a choice is just clearly better. And there are certain fallacies in the air in this regard. Even if party X has won the elections by a landslide for the last 20 years and seem to be governing fairly well, is that an argument for introducing a one-party state?
The fact that they can be voted out of power is what keeps the ruling party honest. (Okay, I mean less crooked, they are politicians, of course...) Similarly, at least having the option of switching to another template engine could be quite important for people.
If it's not a huge headache, I vote for the proxied Context as well. If the api was similar enough to the VelocityContext currently used, converting screens and actions could just be a matter of changing the import statements, and that could be done with a quick search & replace on the source files and a recompile.
As I pointed out in a separate note, FreeMarker (via a custom ObjectWrapper instance) could even be configured to work transparently with VelocityContext objects. It's quite easy.
I'm hesitant to make this following point, since this whole thing about whether removal of FM support was political or not is not something I want to keep debating with anybody. It's all water under the bridge. But, once you know how relatively easy it is to keep the FM support working, and given the fact that offering choice is clearly better, it is hard to make sense of what happened.
Also, the fact that people would create this coupling between Turbine and core Velocity classes makes one wonder how interested these people were in really giving people a choice between multiple template engines.
But it's a sterile debate. If what happened before was a mistake, then the obvious thing to do is to correct that mistake.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Velocity-FreeMarker template conversion utility, http://freemarker.org/usCavalry.html
-Tyler Burd
-----Original Message-----
From: Scott Eade [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 9:24 PM
To: Turbine Users List
Subject: Re: Decimal Number support
At the end of the day, if Velocity has reached EOL then we will at some stage have to consider a new way forward. If FM is being actively developed and provides a good migration path then it is a likely candidate for consideration.
Nobody seemed to express any concerns when WM, FM and Jython support was removed, but at that point in time Velocity was still being actively developed (and as Jeffrey points out Turbines support for all of the others was not). If I was new to Turbine today I think I would be questioning the logic of using Velocity for my templates, but then again if there was no support for anything else then I wouldn't really have a choice would I :-) If FM was supported and there was at least a sample of app that used it then I would probably consider it. The biggest push to use something other than Velocity would be if the Turbine site said something like "Velocity is really great, but no longer being maintained, we recommend you use ??? instead".
As a general direction I think it would be great if we at least look at relaxing the coupling between turbine and velocity such that it would be easier to hook some other template service in should someone have the desire and cycles to put it together.
Cheers,
Scott
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
