Hi Brent,
Am 2019-06-01 um 02:32 schrieb Brent Putman:
Hello,
I represent the Shibboleth project (https://www.shibboleth.net/), a
widely-used open-source platform for federated authentication (SAML,
CAS, and soon OpenID Connect). We make heavy use of Velocity in our
codebase, as well as Spring Framework and Spring MVC.
wow, didn't expect Shibboleth still to be alive, I never understood this
entire complexity if there is Kerberos and TLs cert auth which both
served me well for the last 10 years at work.
As you may know, in their v4.x the Spring folks decided to deprecate
their internal Velocity support for the Spring MVC view layer in an
effort to reduce their maintenance burden. Their (new) philosophy is
that third-party libraries should include Spring support components in
their projects, rather than the other way around. In Spring 5.x they
completed this deprecation process by removing the Velocity view layer
support components from Spring MVC entirely. More details on their
thinking and reasoning here:
https://github.com/spring-projects/spring-framework/issues/18368
My question: From the above issue comments, I see that at least one
person from the Velocity project was aware of this. Does the Velocity
team have any current plans in the works to add Spring MVC support
components into the Velocity project as the Spring team advocates? I
searched in the archives for this list going back awhile and didn't
find anything, but apologies if I missed it.
I do use Spring and Velocity as view with the two-pass approach in a
web-based project. I have been watching the Spring Velocity deprecation
ever since, but was not a committer back then.
If not, then what we wanted to propose/discuss was essentially porting
the latest, terminal Spring 4.x MVC Velocity components into the
Velocity project. We could of course do this within our project
internally (and have provisionally done so, see below), but there would
seem to be significant value for the entire Velocity and Spring user
communities for this to be more widely available and officially
supported by the Velocity project itself. So the main purpose of this
email is to gauge the level of interest in doing this (or conversely
objections to doing so).
The sketch of the proposal would be to add a new Velocity Tools Maven
submodule (e.g. velocity-tools-view-spring), which would align with the
existing Tools project organization. The scope of the code would
likely be very similar to what you see here in our repo, which is how
we are currently supporting development work on our next major version
based on Spring 5:
http://git.shibboleth.net/view/?p=spring-extensions.git;a=tree;f=src/main/java/net/shibboleth/ext/spring/velocity
So it's a relatively small number of classes. If the interest here is
positive, we would be fine with doing the initial work to produce a
patch (unless someone on the Velocity team would prefer to do the work
themselves of course). The main issue I suppose is the Velocity
project taking on long-term support for these components.
We look forward to hearing the Velocity developers' thoughts on this
proposal.
As far as I remember Spring's codebase it covered a lot more than you
have in your Git repo.
How do they compare, would that be a drop-in replacement (except for
package/class names)?
I'd be happy to take a look at it and compare, but due to time
constraint I am not able to work actively on it -- as sad as it sounds.
We can start with small PRs and then grow by time. Ideally, It would be
a complete/better replacement of the previous Spring Velocity module.
as for the name, I wouldn't not call it velocity-tools-view-spring. It
it neither a tool from the Toolbox and neither tied to a view since you
can prduce anything textbased. It'd simply velocity-spring covering all
needs.
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
