Hey, I agree with the restructuring of the jars,
but would like to a separate changes if you are amerceable.
a developer jar and a deployment jar.
Mainly what we have found to be useful here, and if was
available by default might be very useful to the majority of velocity
developers out there, is to setup a stricter environment for our developers.
The idea is that we use velocity from the start, so we don't
tend to ever want to see $something.method() as a result in our templates.
For example, some less rigorous developers might not check the
velocity log file every time they run a test or class. Therefore in the
developers world we use the org.apache.velocity.test.misc.UberspectTestImp
(although a slightly more filled in version)
The obvious advantages here are if someone were to place hard to
see code
Such as
#if($foo.barr()) some obscure text #end
rather than just having to check the log, they would get an Error thrown,
stating
(no method barr in class Foo, template foobar.vm line 3, column 10)
and forcing them to fix the problem.
In development this is a good thing.
In production it is the opposite.
So my point is, a jar for when you are developing, default configured to
highlight errors and mistakes,
And a jar for deploying when you only want the most critical of mistakes to
actually block.
This would also have the greatest impact on newbies, who are both the
most likely to make mistake, lest likely to check the logs, and lest likely
to understand how to change the defaults to make life easier
Llewellyn.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
