A couple months ago I added Ehcache support to CFGroovy2 as an alternative to the simple HashMap/WeakReference caching that had been there since it's inception. I waffled a little bit at the time, but it seemed like the right thing to do. I've changed my mind, and removed the Ehcache functionality in the latest build. If you upgrade and were using Ehcache before, you'll need to either restart your container or manually delete server.cfgroovy.
The <g:manager> tag that I added is still supported in it's entirety, though it's reporting capabilities were really designed for the Ehcache mechanism, so it's not of as much use with the simple caching mechanism. However, you can still clear the cache using it, if you wish.
Another minor tweak has also snuck in: better wrapping of output streams. The Rhino implementation apparently requires a java.io.PrintWriter for it's Writer, where I'd been supplying a java.io.StringWriter. I was programming against the API, but Rhino is more strict. However, I've changed it to a java.io.PrintWriter so Rhino will work. Other languages that only required the Writer type continue to work as before.
Barney, would you expand on the reason you removed ehcache?
Complexity, primarily, particularly around tuning. The HashMap/WeakReference cache is simple, auto-tuning, and has no external dependencies. Ehcache is more complex, must be explicitly tuned, and obviously has an external dependency (though one satisfied out of the box by CF9 and Railo 3.1).
I'd hard coded configuration for Ehcache within script.cfm, and that worked for me, but not necessarily for you. I could have expanded it to look for a pre-configured cache (in ehcache.xml) with a known name before creating the default, and/or provided a means of customizing the one it created, but that adds complexity to a deliberately simple "framework" that I didn't feel was justified. Couple that with the inflexibility of a hard coded configuration, and I just don't think it's the right choice.
If you want to use Ehcache (or any other caching mechanism) with CFGroovy2, it's not hard to implement. The whole "framework" is like 100 lines of CFML, and caching is maybe 10 of them. I think it's better left to people who need a specific solution to provide one, rather than me trying to shoehorn a flexible solution into a space that doesn't need one and will potentially suffer from that shoehorning.