Re: resource loader API change

I agree that if it hadn't been B.C., it would have been a pretty important change, maybe legitimating a velocity2 package. But since ResourceLoader is just deprecated, and inherits from ResourceLoader2, this is *not* a backward-incompatible change. There are some incompatibilities, see

Re: resource loader API change

Not a bad idea. On Sat, Jul 16, 2016 at 12:31 PM, Sergiu Dumitriu wrote: > If more backwards-incompatible changes are going to happen, maybe it's > best to do what several apache-commons project have done: move > everything to org.apache.velocity2. > > On 07/16/2016

Re: resource loader API change

If more backwards-incompatible changes are going to happen, maybe it's best to do what several apache-commons project have done: move everything to org.apache.velocity2. On 07/16/2016 09:11 AM, Nathan Bubna wrote: > I like ResourceReader or ResourceProvider, as i get confused when classes > have

Re: resource loader API change

I like ResourceReader or ResourceProvider, as i get confused when classes have the same name and different packages. :) But i suppose ResourceLoader2 in all its ugliness solves both Will's confusion and my own. Ha! But in all seriousness, you know i'm a big "them that do the work make the call"

Re: resource loader API change

I went on with the "2" suffix, but on the ResourceLoader class, hence a ResourceLoader2 class. Claude On 16/07/2016 10:54, Will Glass-Husain wrote: Makes sense to me. I'm always confused when names are a little similar but not identical. Can we just make a package called velocity2 or

Re: resource loader API change

Makes sense to me. I'm always confused when names are a little similar but not identical. Can we just make a package called velocity2 or util2? Then keep the name the same ResourceLoader. It's a little more awkward sounding but is actually more understandable. Will On Saturday, July 16,