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
