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 <cla...@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-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
