Hi,
Please see my reply inline:
On 14.01.2021 16:21, Daniel Watford wrote:
Hi Eugen,
I like the approach of a config directory which can be used to override
configuration files already compiled into a distribution (distTar/distZip).
It's probably worth opening a separate ticket for that since it would be
analogous to how the /lib directory is currently used for gradle builds.
https://issues.apache.org/jira/browse/OFBIZ-12136
lib/ is not enough. Gradle hardcodes the classpath. Adding jars there
has no effect IMO (see generated bin/ofbiz script). That is why I added
lib-extra/
But my main question was intended to deal with how ofbiz administrators
identify and retrieve the database driver libraries for their deployments.
In your case did you find a list of recommended versions for use with Ofbiz
or did you have a driver that you often use with your DBMS? Did it take
much time to choose the driver?
When talking database drivers I try to pick the latest release.
It's important to match the driver version with database version and JVM
version. With PostgreSQL the latest driver is fine with the postgres 13
(which I am using) and JVM 8 or 11 which I am using.
For other databases it's the same: pick a driver that works with you
database version and your JVM.
Even if it was easy for you to figure out the driver version, do you think
other less experienced ofbiz administrators would struggle? Having the
ofbiz project declare, in code, what library versions are known to work
with various DBMS would reduce the effort required for all administrators.
Yes, for other people it might not be as easy - depending on their
knowledge and expertise - that is why we have community and consultancy
services.
I agree that we probably don't want to change the content of configurations
at build time, but it might be appropriate to break entityengine.xml into
smaller DBMS specific files and then only include one of those files in a
binary distribution specific to a particular DBMS, hopefully making it a
bit easier for ofbiz administrators to get started.
I would split database connection out of the config or have the ability
to use environment properties or java system properties to configure the
connection.
This is better IMO than having to edit configuration files.
If you have an OFBiz build than you can change just supply different
params for DB instead of having to create config files.
Modern configuration libraries have functionality to interpolate
variables in the configuration file with env variables or system
properties. See for example https://github.com/lightbend/config .
My overall aim is to reduce the amount of additional library downloads and
configuration an ofbiz administrator needs to perform in order to get
started. Every step should help get closer to externalising configuration,
as I believe you are already working towards, which should make deploying
and upgrading ofbiz running in containers a bit easier.
Thanks and I'll try to help you with this goal.
Docker makes these deployment issues more visible.
People handle deployment in many ways and with many tools.
I believe documentation is better here than opinionated solutions.
Regards,
--
Eugen Stan
+40720 898 747 / netdava.com
