I think that text is too long to be included in the downloads page
itself, unless we restructure the downloads page. Having a link to docs
about it would be better I think. (As well as being sure that the
download artifacts themselves have README files too-- Adam C. can
manually keep them all in sync! j/k =])
The goal we last discussed was having the bare-minimum of downloads
available directly from the lucee.org site, and then providing links to
“community supported” bundles, so we don’t imply that lucee.org is
responsible for anything beyond the core.
A grip of these community supported bundles should start rolling out
tomorrow, fresh off the presses, for testing and comment.
I’d like to get some feedback on the ideas of, say, putting logs in one
logs directory (with sub-directories, but under one root log dir), as I
think those ideas might make maintenance easier, and we’re already doing
some customization for lucee-tomcat-modcfml-jre (<-- this bundle is the
same-ish as what the current installer installs).
One major new option is the NGINX bundle, which provides the whole
stack, as well as opening up a bag of worms about where the webroot for
the app and web server should be… currently both point at the
tomcat/webapps/ROOT/, but I’d rather use
tomcat/conf/Catalina/hostName/ROOT.xml and have a custom location (maybe
Even better, but unrealistic I think, would be lucee/apps/[name] for the
app root and lucee/apps/[name]/web or lucee/apps/[name]/pub for the web
Although splitting the app code from the pub code may be “too much” for
folks to handle, if we at least used a custom directory for the app
host, we could standardize that location across the bundles too-- for
example, this structure:
So, say, manually upgrading the lucee libs is easy, as is switching
containers… and if we kept the server and web context config
directories under lucee/ as well, along with logs, there would be a
standard location to look for stuff, regardless of chosen flavor.
The tradeoff is that we have to configure* the various underlying
technologies (tomcat, etc.), vs. using their defaults, but we’re already
doing this for the current installer bundle.
*Not configure manually, I mean if an end-user wanted to mimic how the
installer sets up tomcat with a “vanilla” tomcat, they’d have to edit
server.xml, setenv.sh, etc. to achieve the same structure.
-DenOn 3/15/15 12:40 PM, Risto wrote:
I did not write the following. I don’t know if the versions are the
latest in the installer. I copied it from the respective sites just as a
suggestion of what I feel could be a short helpful blurb on download page.