velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Townson <>
Subject Re: a programming exercise integrating velocity with spring ... for general interest of this list
Date Fri, 11 May 2012 17:17:13 GMT
as a follow up to this old thread on the spring-velocity glue library
I wrote some time back, I have picked up this project again after a
long break -- the first part of which is to move to github

the second part will probably be to update the licence ... and, of
course, anyone is now free to make the necessary changes for this,
should they wish :)



On 12 May 2011 01:05, Nathan Bubna <> wrote:
> On Wed, May 11, 2011 at 3:51 PM, Christopher Townson
> <> wrote:
>> The source jar can be obtained from
>> (I need to update the pom details so this gets put into the mvn site
>> properly).
> thanks
>> I should probably move scm at some point, too, so that others can
>> potentially have access to that. Maybe github.
> that's a good idea.
>> As for GPL, that was a religious/political decision ... one can debate
>> the many the finer legal points of the various oss licences endlessly
>> but, since this was something that I did in my own time
>> free-of-charge, I wanted to make it available but I did not want it to
>> be utilised and/or distributed as part of a proprietary/commercial
>> software system (but could still be used by in-house systems where
>> these are not sold/distributed under non-GPL compatible licences). The
>> GNU is also, to my mind at least, the strongest symbol of open source
>> software. There are others, but those are the 2 basic reasons - the
>> GPL stipulates these, whereas apache/bsd do not, afaik. However, if
>> you can make a case for the others, please feel free -- but probably
>> best done off-list ;-)
> Spring and Velocity are both under the Apache license.  So, licensing
> something that integrates the two under the GPL is a non sequitur.
> And this is an Apache list, so you're going to get a little Apache
> sermon, like it or not.
> My employer distributes custom, commercial software utilizing these
> libraries.  We operate in a small niche market where it doesn't make
> sense or cents to open source our distributed products.   In fact, our
> customers would throw fits if we were to use GPL code and have to open
> source (i.e. share with their competitors) the various customizations
> and features they've specially requested.  But it does make great
> sense for us to contribute to open source, commodity code projects
> whose licenses don't try to force us out of business.  Because of
> that, my employer has paid me for most of the time I have spent
> developing Velocity, enabling me to spend far more time on it than i
> would otherwise.  All Velocity users have benefitted from that and
> would not have were it not for the Apache license.
> This are 2 major flaws with GPL: 1) It is untouchable for companies
> like mine, depriving GPL projects of our valuable participation.  2)
> Enforcement is nigh impossible because violation is very difficult to
> detect and legal redress is too costly.
> The Apache approach, however, believes that good communities make the
> best code and good community starts with freedom and goodwill, not
> restrictions.  There are always cheaters and leechers and slapping the
> GPL on your code won't even slow them down.  So, ignore them and focus
> on the honest folks, many of whom can't distribute their end products
> for free.  So, let them do as they will with the code and focus on
> building a good community around a project.  All of the code your
> project is built on and meant for use with was built on goodwill and
> complete freedom of use.  All the community that would potentially use
> it is accustomed to that freedom and goodwill.  Do you really think it
> is wise or feasible to try enforcing new conditions upon them?
>> Cheers,
>> Chris
>> On 11 May 2011 22:23, Nathan Bubna <> wrote:
>>> It's not something i can use yet, and i wasn't able to get the source
>>> in any form.  But the javadoc makes it look thorough, and this is
>>> certainly something that has been sorely missing from Spring
>>> integration.  In general, it sounds great.  But why GPL?  That's
>>> prohibitive for us in future spring/velocity projects.  Apache or BSD
>>> licensing would be great. :)
>>> On Wed, May 11, 2011 at 3:00 AM, Christopher Townson
>>> <> wrote:
>>>> I thought some on this list might like to know about a small "glue
>>>> library" I wrote recently as a programming exercise for integrating
>>>> Velocity with Spring and released on GPL for any interested parties:
>>>> I have often thought that the integration with Velocity currently
>>>> provided by Spring, whilst adequate, could be significantly improved
>>>> -- and this is my attempt to do so.
>>>> I had 4 main aims in this exercise:
>>>> 1. Support the changes to Velocity & Velocity Tools (esp. tools) since
>>>> 1.5 and 2.0 (new toolbox format, no deprecation messages etc)
>>>> 2. Provide a standard, Spring-style means to utilise Spring context
>>>> support to augment velocity tools infrastructure (@ViewHelper
>>>> annotation as a component stereotype which can have a Spring @Scope
>>>> specified automatically added to Velocity context)
>>>> 3. Most importantly: work nicely with ContentNegotiatingViewResolver
>>>> so that a single velocity-based Spring View can be used to generate
>>>> multiple text-based formats simply by dropping in additional templates
>>>> (+ specifying in ContentNegotiatingViewResolver's mediaTypes map)
>>>> 4. Get all of the above to work transparently, out-of-the-box via
>>>> annotations, and correctly determine what sort of "context" the app is
>>>> running in (e.g. web app [access to servlet context] or plain token
>>>> replacer with/without toolbox)
>>>> Any thoughts or feedback would be most welcome ... and, of course,
>>>> feel free to use!
>>>> All the best,
>>>> Chris
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message