Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Velocity support [SPR-13795] #18368

Closed
spring-projects-issues opened this issue Dec 15, 2015 · 4 comments
Closed

Remove Velocity support [SPR-13795] #18368

spring-projects-issues opened this issue Dec 15, 2015 · 4 comments
Assignees
Labels
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Dec 15, 2015

Juergen Hoeller opened SPR-13795 and commented

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.


Issue Links:

  • #18634 Native Support for pebble templates in Spring Web MVC
  • #17826 Deprecate Velocity support
  • #20584 OpenJpaVendorAdapter missing from spring-orm
  • #19029 Documentation still favoring velocity but it is deprecated in 4.3
  • #17884 Drop JasperReports support

Referenced from: commits ff6ead1

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 5, 2016

Claude Brisson commented

Hi, Spring folks.
Velocity folks, here.

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.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 5, 2016

Juergen Hoeller commented

We are not in the business of deprecating Velocity in general in any case ;-) #17826 deprecated our Velocity support package in the core framework distribution, and this issue here is just about actually removing it towards Spring Framework 5.0.

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.

For Spring 5, we are strategically moving away from traditional template-based web views in general. Even just for that reason alone, we are not going to introduce support for any new template engine generations but rather focus on other areas (Jackson integration, JavaScript templates, etc). FWIW, we are going to keep supporting FreeMarker as a sort of reference - in classic Servlet MVC as well as Spring's new reactive web support -, including our generic base classes for template-based views which other support classes may derive from (like the Velocity 1.x based view classes do right now).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 7, 2017

Erwin Vervaet commented

Juergen Hoeller,
It seems Velocity is back :-)
See http://velocity.apache.org/news.html:

Sunday, 6 August 2017

The Velocity developers are pleased to announce the release of Velocity Engine 2.0.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2017

Juergen Hoeller commented

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 (#20584), we do not consider it necessary for those to be part of the Spring distribution which would imply a continued maintenance and integration testing burden for us. We'd rather keep this restricted to FreeMarker on our end.

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants