Hi Eugen, I think your point...
> It's important to match the driver version with database version ... is a good reason for the ofbiz project to NOT be opinionated about database libraries and versions Originally I had only thought we would need to specify one driver for one DBMS type. I had failed to realise there would be lots of different versions of any one DBMS in use, each potentially requiring a different driver version. Figuring out the 'good' driver version for each DBMS version potentially used with ofbiz probably wouldn't be workable. I imagine at best we might have a web page where ofbiz administrators can report on the combination of DBMS version, driver and JVM they are successfully using. You've changed my mind! :) I'll drop the use of build-time properties to resolve database driver libraries. Thanks, Dan. On Thu, 14 Jan 2021 at 15:37, Eugen Stan <eugen.s...@netdava.com> wrote: > 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 > -- Daniel Watford
