Release Candidate 4 (last before stable on Monday)

Could we get a Dockerized build ? It looks like there haven’t been any since 3 months ago.
This would let us plug the RC straight into our testing systems, as we’re using Docker all the way through the stages to live, and we are based off the official Lucee images.

I also echo what @bdw429s says - Lucee should work without doing any downloads beyond the initial install/image; we deploy Lucee in regulated environments, sometimes with no Internet access.

I believe @modius or @justincarter normally help kick off the Lucee docker images for snapshots. I’ll note if you’re using the Ortus CommandBox-based docker image you always have access to 100% of all Lucee versions ever produced as every snapshot is automatically published to ForgeBox within the day.

@bdw429s Version 1.2.0 and is NOT the same version.

According to how every other software I’ve ever used treats semantic versions, yes that should match. If 1.2.0 is treated correctly as a sem ver “range”, then it will de-sugar to 1.2.0.x where the x can match anything. This is how/why other package managers like npm or ForgeBox, let you do:

install coldbox@6
install coldbox@6.7
install coldbox@6.7.1
install coldbox@6.7.1+2

and all of those commands will match and install the version 6.7.1+2. This is how the world does versioning. So, 1.2.0 should in fact match in my opinion.


In OSGi version number do not left room for interpretation, this version number are not the same and not even by accident, the “L” at the end stands for “Lucee”. For the Lucee team this is clear cut, we have version “1.2.0” of the axis lib with correction “0000L” of the Lucee team when we did convert it to a OSGi bundle.
For Felix (OSGi engine used by Lucee), this numbers are never the same and Felix would never load 1.2.0 when is defined (visa versa).

In this example you see an exception from the Lucee core, because Lucee is trying to resolve the issue, Felix did complain about. Felix cannot resolve and for example download missing jars, Felix need to be spoon feeded with bundles by Lucee.

But a good example is when Felix complains about “Uses constraint violation”, we saw for example with the S3 extension recently with exactly this bundles! one chain in the S3 extension jar did use “” and the other “1.2.0” what caused OSGi to throw a “Uses constraint violation” exception.

I think your confusion comes from the possibility to define a version range, instead of a specific version.
Of course that is also possible in OSGi but that is a different syntax.
but that is a different story.

In this case the issue is with the axis jar that defines “org.lucee.commons.logging;bundle-version=1.2.0”, what then forces Felix to load this version, it cannot and that triggers Lucee to resolve that version what fails.

BTW also Maven contradict you, otherwise this would not be possible https://mvnrepository.com/artifact/org.lucee/axis

“According to how every other software I’ve ever used treats semantic versions, yes that should match.”
i saw my first Black Swan when i was 30 :wink:

If Lucee wants to have its own version of a bundle, shouldn’t it be using a separate bundle name? And if Lucee is using a separate bundle name, what is the utility of a custom “L” in the version when the bundle is already unique?

Umm, maven seems to be contradicting itself :wink:


I’m not really sure what you are saying, i think you confuse Maven and OSGi a little bit.
The original Maven groupid is “axis” and the artifactid is also “axis”. Our group id is “org.lucee” and the artifact we use is “axis”, so that of course differ, i cannot create versions for the group “axis” only the owner of this group can. See the maven groupid like a domain and the artifactid like a subdomain.

We do the bundle name “org.lucee.axis”, that way we have not to define a maven->osgi mapping.

Normally we use the original version number one to one with no appendix, but in that case we had to do some changes in the OSGi conversions process, like for example updating a required bundle or any other relation. otherwise that extension would use a different version of apache.commons.logging as for example S3 does, that works fine but of course is a waste of resources. Sure we could define a range in that case, but that has the risk that a never version no longer is compatible with axis. Axis for example uses a older version of the apache.httpcomponents than other extensions do.

That the “L” is once in the beginning and once in the end, is simply because we (Lucee) changed the pattern over time. That has nothing to do with Maven itself, Maven simply takes the version numbers as they are given, BUT maven never allows to update versions (only for SNAPSHOT that are of course not released), that clearly shows that this are also different version for Maven, another black swan :wink: fixed these problems, stable release tomorrow

In the meantime, if anyone wants to try out the preview installers, that would be great!

see Preview installers


Thanks for everyone’s hard work getting out this release! Please update the docker images when you get a chance as that’s the only way my workflow is setup to test and deploy.


Can we expect a release today (Apr 27, 2022)?

YES! Today we will release 5.3.9 stable

As just the installer ? Or with Docker and .jar versions as well ?

nah, just a screenshot of it running on my machine!

1 Like

actually, just dived into lucee docker land, it’s still done via travis and we have run out of credits since they got taken over by VCs, so we need to migrate the build process to github actions

@justincarter looks after this side of things and it’s after midnight down under, so the docker builds will take a bit longer, but they will happen (also snapshots)


Justin has only been here for 10mins in the last 2 months, unless the forum hover text is wrong, so hopefully he reads the ping from Jira :slight_smile:

all under control :slight_smile:

@justincarter @Zackster If you reach out to Travis support for whatever account the docker builds are under and ask for some free credits because your project is open source, they’ll usually reply (and oblige) that day. It’s not a long term fix, but it is a shorter-term fix than converting to GA today :slight_smile:

@modius is sorting out Travis, not sure if they’ll hand out open source credits since we use Open Collective

I’ve translated the travis job to github actions, needs some secrets setup etc

Also, time to change 5.2 to 6.0


After a few small hurdles the GitHub Actions workflow is now working for manual builds and all the latest Lucee Docker images have been built and pushed. Snapshots will be available again soon after the trigger is fired from the Lucee build process.