[SPR-13795] Remove Velocity support Created: 15/Dec/15 Updated: 02/Oct/17 Resolved: 04/Jul/16
|Fix Version/s:||5.0 M1|
|Reporter:||Juergen Hoeller||Assignee:||Juergen Hoeller|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Days since last comment:||50 weeks, 3 days ago|
|Last commented by a User:||false|
Velocity 1.7 dates back to 2010. Following up on the deprecation of our Velocity support in Spring 4.3, let's not include it to begin with in the 5.0 generation.
|Comment by Claude Brisson [ 05/Jul/16 ]|
Hi, Spring folks.
While you may legitimately deprecate Velocity 1.7, be sure not to deprecate Velocity as a whole: despite the lack of releases in the last few years, Velocity has been continuously maintained and we're ready to release a 2.0 version. I hope we'll find the time to do it very soon.
|Comment by Juergen Hoeller [ 05/Jul/16 ]|
We are not in the business of deprecating Velocity in general in any case
In the end, we don't want to drag along an outdated dependency - with a limited audience among Spring developers in the meantime - into a new major generation of the framework. Note that our traditional Velocity support package remains around in Spring Framework 4.3.x which we're maintaining until 2019. We have been reducing our optional third-party dependencies for a while, asking maintainers to ship Spring support on their end instead, e.g. for Thymeleaf and Ibatis. Feel free to do this for Velocity 2.0 as well as it materializes, even with support for Spring Framework 4.x since the View contract remains identical anyway.
|Comment by Erwin Vervaet [ 07/Sep/17 ]|
|Comment by Juergen Hoeller [ 02/Oct/17 ]|
As mentioned above, any stakeholders there, please ask the Velocity team to ship Spring adapters for Velocity 2.0 themselves, along the lines of Thymeleaf where this has turned out as a very successful model. As with OpenJPA (
In general, we're trying to reduce third-party adapters in the core Spring distribution to two 'reference' implementations per case - validating our abstractions but not aiming for completeness there: e.g. Hibernate + EclipseLink for special JPA features, FreeMarker + Groovy for template rendering, etc. Note that we do not ship a DataNucleus adapter, and as mentioned no Thymeleaf adapter either (despite it being more popular than FreeMarker these days).