"Core" version of Lucee

There have been discussions internally at LAS for a while now around providing a “core” version of Lucee alongside the existing “full” versions of Lucee. This “core” version would essentially exclude everything that is now an “extension”, e.g. database functionality, PDF functionality, charts, forms, etc… I’ve raised a ticket for it on the Lucee JIRA here:

https://luceeserver.atlassian.net/browse/LDEV-1583

Please go to the ticket for more details and vote for it if you would like this “core” version of Lucee to be made available and/or give your opinion here in the forum.

Thanks.

I commented on the ticket, but I’ll post it here as well in case any local conversation ensues:

I think this sounds very interesting-- especially for CommandBox. My big question is if it’s possible for extensions to be installed on-demand when code tries to use features from them. That may be a non-trivial request. I’m just thinking it would be cool to have a super stripped down version of Lucee in CommandBox, but then if a person writes a task runner that accesses a MySQL database, it would be sweet if CommandBox/Lucee just downloaded that extension on the fly the first time and everything “just worked”. It’s not a deal breaker, but it does seem like that would be pretty cool if there was any significant savings in initial jar download size and/or startup time with fewer bundles to load.

2 Likes

Please note that there is nothing “light” in this version. It is the same Lucee engine, just without the 3rd party libraries all bundled together.

It’s the Lucee core with Lucee loader.

This makes sense for dynamic loaders. The situation that we are trying to solve (maybe unrelated) is that of being able to pre-bake a version. So for example you would have a bundle level of X that you can just tell Lucee to load up since this would be a version with all the extensions that your app needs.

Let me re-phrase that, basically I have an application (let’s call it a Todo app! ) that needs ORM and MySQL and Mongo extensions. I don’t want these to be loaded at runtime when my users are doing it, but as part of the startup. So If I have run my application I could get a unique code that I can plug somewhere into Lucee Light that when my docker instance starts up it goes and downloads the extensions it needs before starting up and it’s ready to do work without waiting for the first person to hit it.

Make sense?

@markdrew You can do that already with this new “core” (don’t want to offend @21Solutions calling it “light” :slight_smile: ) version. Simply add commands to your Dockerfile to download the required extensions and copy them to the deploy directory. Then when your servlet container (e.g. Tomcat) starts it will install them.

@21Solutions Agree, it is not “light”, it is “core”, I’ve updated the title of the post.

Well, the thing is that we already call something else core – the .lco file that we contains code from the Lucee core project: Lucee/core at master · lucee/Lucee · GitHub

As I’m sure you already know, Lucee is made of two main parts: Loader and Core. Loader is a jar that exposes the API. Core is loaded by Loader (hence the name) so that we can update Lucee without restarting the JVM.

So in a sense, this packaging is a Loader distribution, but I guess for the sake of simplicity we can call it Core. The thing is that we already distribute the .lco as Core file (*.lco).

Confused? So am I :wink:

2 Likes