BTW worth posting here that we successfully shifted from Lucee-full-fat to Lucee Light last week, and was a) pretty painless; b) seems fine. Would have preferred clearer guidance on what's in and what's out of the Light version, but fortunately we have enough test coverage to find the extensions we were missing. So... that's a Lucee "Good News" story. Cheers to the help @Mark Drew (he/him) gave me en route on this.

Just curious, what do you feel like the "wins" from moving from the "fat jar" to the light version? Was it primarily the reduction in vulnerabilities (since you have less 3rd party dependency)? Are you seeing other gains?

"win" was primarily that it went smoothly and did not waste much of my time. Which can't be said for some Lucee upgrades I've done in the last coupla years. More materially: 100% it is "fewer vulns", and smaller footprint to be susceptible to same.

Thanks! I wasn't sure if there were any performance reasons you were doing it (like faster spin up time of new nodes, etc).

@Adam Cameron Via this work - do you have a list you can share about what is in/out of the light vs fat versions?

@dswitzer -- when we made our move, it allowed us to move to smaller containers for apps that didn't have much going on. Fat/regular Lucee usually sat best in a 2GB container. Light easily goes into my 1GB setup (super small apps can go in 512MB). Zero also goes into 512MB/1GB for many apps. These aren't things like Masa, but framework-less apps and simple API servers, it makes a difference. Plus the entire vulnerability threat-scape.

@dswitzer we don't have performance issues with spin-up time, so had not been looking at it. Container destruction, rebuild & run only takes a few seconds already. Image size went from 650MB to 470MB. Not really a concern for us, but it's a thing. @gavinbaumanis our requirements were not exhaustive, but we needed to add ESAPI, image, MySQL, "compress tags" and PDF extensions.

Thanks for sharing all. Good food for thought!

we did this maybe a year ago. the only pain for us was that the extension mechanism isn't a full-fledged package manager, in that it doesn't deal with transitive dependencies. in other words, if extension A relies on extension B, you've gotta figure that out yourself. also, your automated tests will probably bear things out, but of course you've got to figure out which extensions to install when you're starting from scratch. some of them power BIFs and might not be obviously extension-supported.

Yeah. Lucee hasn't thought things through. This is not "stop the presses", it's "caveat emptor"

I agree... BUT... Being open-source, and with a reasonably small number of committers and a smaller number of active committers, there is only so much that can be done. It's a separate topic, certainly, but perhaps Lucee needs to do some "active" recruiting.