Hand crafting 5.0 build from JARs

hacking
1

Have got a working build of Lucee 5 PREVIEW (“Velvet”) put together from the JARs distro for the Lucee 5 Docker containers. Thought it might be worth highlighting how this is constructed for others who might be trying to hand craft “Velvet” builds.

Things will likely change for the better as we move toward a GA release but for now there are four parts to the build:

  • core lucee core JAR
  • org.apache.felix.framework-4.2.1.jar; OSGi framework
  • lucee dependencies ZIP
  • lucee extensions (cobbled together from Express build)

Assuming a standard linux based install similar to the official installers for Tomcat 8 you might assemble things as follows…

Lucee Jar

Lucee core is super small, and easily available as an automated build called JAR. Unfortunately, if you are used to getting the old JARs distro this is not it! You will need to pull down Lucee core and place it in your Tomcat install like so:

cp /tmp/lucee.jar /usr/local/tomcat/lucee/lucee.jar

OSGi framework

The Felix framework is critical to get things working, but its completely missing from the list of artefacts Lucee provides at the moment. Get hold of Felix by hook or by crook and put him next to lucee.jar like so:

cp /tmp/lucee.jar /usr/local/tomcat/lucee/org.apache.felix.framework-4.2.1.jar

Dependencies

The Dependencies comes as a ZIP of all the needed JAR libs. You need to unpack them into a new folder called bundles:

unzip /tmp/lucee-jars.zip -d /opt/lucee/server/lucee-server/bundles

Extensions

Last but not least you need the Extensions. Seeing as everything in Lucee 5 is going to be extensions, these are pretty critical. Unfortunately, there is currently no automated distribution of the latest extensions although thankfully they are not particularly volatile. You can snarf them from the Express install; the files with the .lex extension.

The Extensions must be copied into the ./deploy folder like so:

cp extensions/ /opt/lucee/server/lucee-server/context/deploy/

When Lucee 5 starts up it scans the deploy directory, installs any extension it finds, and deletes the extension packages from the folder.

Enjoy!

Dockerfile

If you want to have a play you can always spin up the Vagrantfile workbench we have for the Lucee Dockerfiles project.

The Lucee 5 Dockerfile, related assets and configs are all available on Github at:

Full Lucee 5.0 Dockerfile available below so you don’t have to go hunting:

FROM tomcat:8-jre8

MAINTAINER Geoff Bowers <modius@daemon.com.au>

ENV LUCEE_JARS_URL http://daemon-provisioning-resources.s3.amazonaws.com/lucee/5.0/lucee-5.0.0.98-20151023.035428-4.jar
ENV LUCEE_DEPS_URL http://daemon-provisioning-resources.s3.amazonaws.com/lucee/5.0/lucee-5.0.0.98-BETA-dependencies.zip

# Download core JAR, and delete it in one step to avoid committing the installer in a FS layer
RUN wget -nv $LUCEE_JARS_URL -O /root/lucee.jar && \
	mkdir -p /usr/local/tomcat/lucee && \
	cp /root/lucee.jar /usr/local/tomcat/lucee/lucee.jar && \
	rm -rf /root/lucee.jar

# COPY over random missing dependencies; OSGi framework
COPY org.apache.felix.framework-4.2.1.jar /usr/local/tomcat/lucee/

# Download lucee dependencies
RUN wget -nv $LUCEE_DEPS_URL -O /root/lucee-jars.zip && \
	mkdir -p /opt/lucee/server/lucee-server/bundles && \
	unzip /root/lucee-jars.zip -d /opt/lucee/server/lucee-server/bundles && \
	rm -rf /root/lucee-jars.zip

# COPY over Lucee extensions
RUN mkdir -p /opt/lucee/server/lucee-server/context/deploy /opt/lucee/web
COPY extensions/ /opt/lucee/server/lucee-server/context/deploy/

# Delete the default Tomcat webapps so they aren't deployed at startup
RUN rm -rf /usr/local/tomcat/webapps/*

# Set Tomcat config to load Lucee
COPY catalina.properties server.xml web.xml /usr/local/tomcat/conf/

# Custom setenv.sh to load Lucee
COPY setenv.sh /usr/local/tomcat/bin/
RUN chmod a+x /usr/local/tomcat/bin/setenv.sh

# Create Lucee configs
COPY lucee-server.xml /opt/lucee/server/lucee-server/context/lucee-server.xml
COPY lucee-web.xml.cfm /opt/lucee/web/lucee-web.xml.cfm

# Create webroot with a default index.cfm
RUN mkdir -p /var/www
COPY index.cfm /var/www/

# Remove test page when used as base image
ONBUILD RUN rm -rf /var/www/*
2

some thoughts from me.

merge felix and lucee
We should consider to merge felix and Lucee into one jar, then Lucee needs this jar to live, otherwise it cannot start up, so while not merge the code from felix into the lucee.jar in the build process.

extension
i’m working on a download page that works the same way as this http://preview.lucee.org/download/, so it provides all extension available from the extension provider, ATM extension are still build manually with ant, but i plan to move them to maven asap, so that every commit triggers a new snapshot that is available as extension in the admin and on the download page.

we could even consider that you can download Lucee with pre bundled extension of your choosing, so on the download page you could choose the extension you like, let’s say hibernate, lucene and mysql, then you generate a permanent link to exactly that bundle constelation, most popular permanent links could be shown on the download page.

We should also consider to bundle some extensions always, like most jdbc drivers for example (have in mind that extension are not necessary loaded when bundled, so for example jdbc drivers are only loaded when used).

The point is that extensions can be bundled in the lucee.jar like we always bundle a core file (.lco) what is not that different from an extension.

dependencies
I’m not sure at all about this, but we could also do a lucee.jar that has bundled all dependencies, so you could have a lucee.jar that contains everything, the dependencies necessary and the extensions of your choosing, so everything necessary to execute lucee would be in that lucee.jar, for sure one big file, but for many cases this could be very helpful, install lucee only by adding the lucee.jar in the right place. as more as i think about as more i like this.

1 Like
3

absolutely - this would greatly assist in setting up maven-ized web projects.

you could also deploy the .lex/.lar files as maven artifacts so that they can be added as dependencies.

4

This is what i plan to do, but i have some troubles to get this working

5

What I’ve done (probably not the “right” way) is to set the packaging to
jar, then prevent the default jar plugin from running, then add my own
packaging step (for example a special jar step that builds a lex), and
finally use codehaus’ build-helper plugin to attach that as an artifact. It
does display an info message during install/deploy stating the default
artifact could not be found, but it otherwise works…

Then I can include that dependency as type lex from another project.

I’m working on some blog posts about my experiments with Lucee+Maven.
Hopefully I’ll get the first one out today.

6

for the moment this has not the highest priority for me, atm all extension are ANT based, but i plan to convert them to maven as well, but then i will need to be able to build .lex artifacts, that i can define as dependency in Lucee.
The idea for the future is that the current Lucee core (.lco) is also only an extension (.lex).

8

I have a problem with this idea. What if I want to start from the Felix end of the process? When I learned about Lucee going to OSGi I started learning about Felix. I should be able to deploy Lucee on to a Felix installation. While it might never be the norm for a Lucee install I should be able to do it.

9

LAS has recently started releasing a lucee-all.jar that includes lucee core, felix, all dependencies, and all official extensions. It might be worth experimenting with this to see if it causes your set up problems.

Once we have a GA platform we are looking at providing a custom configuration tool for advanced deployments where you can choose what componentry should be installed within your distribution of lucee.jar. I’m sure it would be possible to enable a felix free version of the distribution using this tool.