Looking at the build scripts, it could go in a theme specific SAR.
If folks think this is a good thing, it could go into the nukes.ear in the nukes-lib.jar, so it is available as a general service. If this is the case, then the templates should be called out in the MBean config in some way, so that multiple Velocity based themes can be available.
i have a small concern over this...
while nukes does give ppl the flexibility to do things like this (and i think that is a great feature), i feel this makes things more complicated as well.
now there are multiple templating mechanisms being used, which makes it makes it much more difficult for ppl to come up w/ drop in templates to change look and feel (of course, it's not like we have html ppl lined up at the door to churn out nukes themes, but maybe some day).
we already have the html templating mechanism, and work is being done to allow jsp support as well. if you ever wanted to release this module to the community, velocity make three. while flexibility is good, i have a concern that too much flexibility will make nukes look less attractive as a solution.
Personally, I would love Velocity based templates.
Scaleability aside, I was attracted to Nukes because it seems to be a simple to use, yet powerful, Java framework. I applaud that simplicity of use, and don't want to make it "less attactive" to others.
OTH, Java is more powerful than PHP, and hence Nukes is more complex. Is the goal to be a PHPNuke drop-in replacement for PHP users, in which case why not use PHP?
So far, the "velocity theme" is completely non-intrusive to the core, so it's a matter of preference whether it's "deployed" or not for the forseeable future (one reason I want to "package" it correctly so that it won't conflict with other packages and is self contained). Work can continue independently and work with the current (and hopefully future) Theme API.
There are some issues that could better be solved in the core, however IMO the "appropriate" solution to that is a pluggable templating system, not core Velicity support, per se.
As for the current template engine, after having traversed the Page code all the way down to WriterParser, I found it much simpler to drop in Velocity and throw a Bean in the Context than trying to figure out how to extend the current parser to expose certain methods. Yes, I'm lazy. Call it false laziness if you like, but there it is.
JSP's won't work for my application, for various technical and non-technical reasons -- many of them the same that I'm not wanting to use PHP in the first place.
In summary, I would better like to understand the "vision" of Nukes, and help make it successful.
I want to use my Java tools of choice - Velocity, JAAS, JMX, J2EE, JAS (Java Alphabet Soup) ad infinitum without the complexity (and forced design desicions) of some of the other frameworks. Where's the balance? With Nukes, can I have my cake and eat it too?
There's another point to consider here as well.
Velocity is a well known templating system. You open the door to a sizeable crew of Java developers by including it as an option within Nukes.
Also, the presentation layer aspect of Nukes is still a little esoteric. You can consider this an uninformed comment, I've spent some time writing my own theme in Nukes and learning to accept its various formatting idiosyncracies. This was a frustrating experience - I don't want to learn yet another technique for doing something simple like controlling the way objects can be given as output to a page ....
I think you should be able to add this as an option for people to install if they want to use it. It doesn't have to be a core feature but if someone wants the ability to use it why not have the option?