You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Brent Putman <pu...@georgetown.edu> on 2019/06/01 00:32:12 UTC
Velocity + Spring MVC
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.
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.
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.
Thanks,
Brent
Re: Velocity + Spring MVC
Posted by Brent Putman <pu...@georgetown.edu>.
On 6/2/19 2:06 PM, Michael Osipov wrote:
>
> 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.
It's been very much alive for over 15 years, very widely used around
the world in higher-ed and elsewhere. Kerberos and client TLS don't
really address the same use cases as web SSO protocols like SAML and
OIDC. But that's a topic for different list and/or off-list.
>
> As far as I remember Spring's codebase it covered a lot more than you
> have in your Git repo.
Yes, you are correct (although maybe not a *lot* more). My colleague
who did that work didn't side-port quite everything, he omitted some
things we don't use. I remembered this whilst doing some preliminary
work on this on Sat and was going to report that, but you beat me to
it. Apologies for the confusion.
What I was proposing to do was do a complete port/migration of the
Velocity support code in Spring's terminal 4.x release (currently
4.3.24.RELEASE). That would be the primary 'main' classpath code in
these 2 packages from their 2 Maven modules:
https://github.com/spring-projects/spring-framework/tree/v4.3.24.RELEASE/spring-context-support/src/main/java/org/springframework/ui/velocity
https://github.com/spring-projects/spring-framework/tree/v4.3.24.RELEASE/spring-webmvc/src/main/java/org/springframework/web/servlet/view/velocity
as well as related unit tests and some resource files.
But it's still only 11 classes. So the scope of this isn't that large,
unless I have missing something hiding in other packages or modules.
>
> How do they compare, would that be a drop-in replacement (except for
> package/class names)?
I was pretty much hoping to bring those over as-is as much as possible,
so that the initial version would pretty much be a drop-in replacement
for the existing code, with only package names changed. My colleague
said he thought there were some changes for the Spring 4 -> 5
transition, but that is likely minimal.
> 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.
>
If there's other features and capabilities that make sense to add, that
is fine. Timewise I would personally advocate for getting a straight
port of the existing functionality done and released first, to help out
all the folks that want to update to Spring 5, but can't easily do so
b/c they depend on Velocity.
> 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.
>
I'll defer to the Velocity devs for sensible module naming. Since the
spring-context-support stuff is not MVC view related, and indeed
Velocity is used for non-web template cases as you point out, I agree
with omitting the "-view-" part.
Aside from the name, I guess the main initial decision would be from
which of the Velocity parent POMs should this inherit.
Thanks,
Brent
Re: Velocity + Spring MVC
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Velocity + Spring MVC
Posted by Michael Osipov <mi...@apache.org>.
Am 2019-06-03 um 08:02 schrieb Brent Putman:
>
> On 6/1/19 12:25 PM, Nathan Bubna wrote:
>> Yeah, adopting Spring support is unlikely to be much burden and seems well
>> worthwhile.
>>
>> On Sat, Jun 1, 2019 at 1:48 AM Claude Brisson <cl...@renegat.net.invalid>
>> wrote:
>>
>>> Hi.
>>>
>>> We are aware of the situation, and we were more or less expecting
>>> someone to make such a proposal. Yes, it will benefit both communities.
>>>
>>> +1 for me. I guess that if your patch includes proper test cases,
>>> support won't be problematic.
>>>
>>> Claude
>>
>
> Ok, great, thanks Claude and Nathan for the positive feedback.
>
> I'm just about to head out for a couple of weeks of vacation, but I'll
> look to do some work on this later in June. I'll be in touch with any
> questions.
>
> I do have 2 initial questions:
>
> 1) From the POMs it looks like Velocity is still primarily using
> Apache's Subversion repo, but there are also GitHub mirrors. Didn't
> know how "official" the latter are. Would doing the work in Git and
> doing GitHub pull-requests work here, or do I need to produce a
> Subversion-compatible patch?
PRs are fine.
> 2) Do you have any upcoming release(s) scheduled that I should know
> about and work around? If you have one coming up in July/August, I
> could probably make that.
As always with OSS: it is done when it is done ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Velocity + Spring MVC
Posted by Brent Putman <pu...@georgetown.edu>.
On 6/1/19 12:25 PM, Nathan Bubna wrote:
> Yeah, adopting Spring support is unlikely to be much burden and seems well
> worthwhile.
>
> On Sat, Jun 1, 2019 at 1:48 AM Claude Brisson <cl...@renegat.net.invalid>
> wrote:
>
>> Hi.
>>
>> We are aware of the situation, and we were more or less expecting
>> someone to make such a proposal. Yes, it will benefit both communities.
>>
>> +1 for me. I guess that if your patch includes proper test cases,
>> support won't be problematic.
>>
>> Claude
>
Ok, great, thanks Claude and Nathan for the positive feedback.
I'm just about to head out for a couple of weeks of vacation, but I'll
look to do some work on this later in June. I'll be in touch with any
questions.
I do have 2 initial questions:
1) From the POMs it looks like Velocity is still primarily using
Apache's Subversion repo, but there are also GitHub mirrors. Didn't
know how "official" the latter are. Would doing the work in Git and
doing GitHub pull-requests work here, or do I need to produce a
Subversion-compatible patch?
2) Do you have any upcoming release(s) scheduled that I should know
about and work around? If you have one coming up in July/August, I
could probably make that.
Thanks,
Brent
Re: Velocity + Spring MVC
Posted by Nathan Bubna <nb...@gmail.com>.
Yeah, adopting Spring support is unlikely to be much burden and seems well
worthwhile.
On Sat, Jun 1, 2019 at 1:48 AM Claude Brisson <cl...@renegat.net.invalid>
wrote:
> Hi.
>
> We are aware of the situation, and we were more or less expecting
> someone to make such a proposal. Yes, it will benefit both communities.
>
> +1 for me. I guess that if your patch includes proper test cases,
> support won't be problematic.
>
> Claude
>
> On 01/06/2019 02:32, Brent Putman wrote:
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Thanks,
> > Brent
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: Velocity + Spring MVC
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
Hi.
We are aware of the situation, and we were more or less expecting
someone to make such a proposal. Yes, it will benefit both communities.
+1 for me. I guess that if your patch includes proper test cases,
support won't be problematic.
Claude
On 01/06/2019 02:32, Brent Putman wrote:
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> Brent
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org