I’m confused. The PostgreSQL driver on the lucee page shows versions schemes that line up with upstream’s.
Despite what Justin said, from my understanding, all Lucee extensions that are based heavily on a specific external Java library have a version that simply matches that of the bundled library. This is really just done for convenience since it would be difficult to remember which version of a JDBC driver bundled which actual version of the Java library.
Same with HttpComponents
There is no HTTPComponents extension so I’m not sure what you mean by that.
Typically, packaging software that requires downstream releases (e.g. Linux package managers) append extra information at the end, so it’s very reasonable to keep the versions in sync. For instance, my Bash version as packaged by my distro is 5.0.011-2
, signifying that the packager pushed a change for the same version.
You’re correct that is common, but I don’t think Lucee adds anything. Most upstream Java libs already have 4-party version numbers and Java libs don’t usually use a hyphen unless it’s a release identifier like -RC or -snapshot. So far as I know, there is no plan in place for how to deal with a second or third build to a Lucee extension that bundles the same upstream lib. This was all architected by Micha who doesn’t monitor this forum. I realize you don’t want to put in tickets, but you’re only going to get people guessing as to what Micha’s design was since no one else really knows or was consulted about it.
The bigger picture question is… What is the purpose of most of those .lex files in any case?
I believe you have a faulty understanding of what an extension is. This is like asking what the purpose of a McDonalds value meal is when you can just purchase a burger directly. An extension is just a package that can (or cannot) have a number of things
- zero or more OSGI bundles
- zero or more plugins to the Lucee admin
- zero or more custom functions
- zero or more custom tags
- zero or more Cache drivers for the admin
- zero or more JDBC drivers for the admin
So while a Lucee extension (which is bundled as a zip file bearing a .lex file extension) may have OSGI bundles inside of it, extensions serve a grander purpose than simply being a bundle.
With Lucee’s ability to run OSGi bundles the downloads page merely looks like an unloved re-hosting of various components!
How does the fact that Lucee uses OSGI bundles relate in any way to the download page for extensions? These are unrelated concepts. Also, what exactly is “unloved” about the download page?
Are you saying the contents look old? Or unsightly? I’m not following.
AFAICT there is no LTS version of Lucee; Only the latest version is supported.
Depends on how you look at it. The community is free to “support” Lucee for as long as they wish. It’s open source. LAS doesn’t support Lucee at all strictly speaking. You put in tickets and you just hope they get worked on. Companies such as Rasia provide paid support for pretty much any version of Lucee so long as you’re willing to pay for the fixes.
Now, as far as which versions get updates, Lucee does usually have more than one iron in the fire. For example, the 5.2 branch has gone dark, but the 5.3 branch just released 5.3.4.80, and there’s a release candidate out for 5.3.5 and also snapshot builds already present for 5.3.6. Case in point: 5.3.4.77 recently came out and some regressions were addressed in it which led to the 5.3.4.80 release even though 5.3.5. and 5.3.6 are already under development. So no, commits are not only added to the very latest version.
If that’s the case, why are .lex files still distributed when OSGi counterparts exist?
It’s not the case, but to answer your question-- for the same reason McDonalds still sells value meals given the fact they also sell fries and burgers. Extensions are a package of things which may or may not include any ODSI bundles.
My best guess is that it facilitates the one-click installs from the lucee admin
One click installs from the admin are great for extensions, but that’s not really why they exist. See above.
but I argue that the ecosystem is made too complicated
Software development is complicated. I don’t personally see any unnecessary complications here. Extensions tend to bundle self contained features. These features are often built upon a 3rd party jar. These jars are converted to OSGI bundles if necessary and packaged inside the extension they power.
by forking these components
Who’s forking anything? When Lucee bundles a 3rd party java lib, they don’t have a fork of it. They simply include the jars.
(and in the case of e.g. the S3 extension’s dependence on an ancient bouncycastle, insecure!).
Outdated dependencies are something we have to manage regardless. If you’re concerned about the version of bouncy being used in the S3 extension, please search te bug tracker and enter a new ticket if there isn’t one. If it’s incredibly important to you, hire Rasia and pay for it to get updated or submit a pull request for the update.
The Lucee devs are great at making Lucee; they shouldn’t be in the business of packaging software.
On what grounds? Lucee is inherently a modular architecture, made to have a light core and a collection of ancillary extensions that augment the functionality of the core. The very nature of this demands some sort of packaging and installation process.
HTTP/1.1 501 HTTPS Required
I actually thought I went through and removed all the HTTP URLs from our data provider the other day. Perhaps I missed one. The code is here, feel free to track it down and send a pull. You can spin up this site as a local REST API pretty easy with CommandBox, but you do have to create the REST mapping manually:
Note Lucee’s server doesn’t host these files, it just serves as a redirect to the actual Maven repo so Lucee can “auto-download” bundles if they are required but not installed. I’m not a huge fan of that functionality, but it is what it is I suppose.
While I can individually report bugs for broken downloads, I’m more interested in discussion of the extension ecosystem as a whole - Bug tracking systems are typically not an appropriate avenue for that. I’m not sure of a better place to start this discussion than Lucee’s own dev forum.
Right, the discussion part is fine. But anything that’s broken needs a ticket. As Micha says, if there’s no ticket, the bug doesn’t exist! Also, as soon as you get too far off in the weeds of “why was it designed this way” then you get to questions that really only Micha can answer. And the only place I’ve seem him speak “publicly” in years is in JIRA.