JDBC Drivers in Moqui

Is there a reason that JDBC drivers have to be installed manually in Moqui? @jonesde

If I were to guess, JDBC drivers aren’t included in Moqui because they are inherently optional. You only will ever choose one or maybe just use the default H2 database.

Shouldn’t there be a component for installing the JDBC drivers and setting up configuration for commonly used databases? Each component has a MoquiConf.xml file. In that file you should be able to specify where the JDBC driver is and all you’ll have to do is change the password and username (and possibly the ports). That would make it signifigantly easier for future people using Moqui to setup moqui with a database.

In the moqui-framework component JDBC driver JAR files can be added in framework/build.gradle file. For example the Postgres JDBC driver is here:


There are 2 main reasons, which vary by driver, for not including them by default:

  1. size (postgres 981KB, mysql 2.3MB)
  2. license (postgres is fine with BSD 2-clause; mysql uses GPL 2.0 which may be an issue even being on the classpath, or using references to class names that implement JDBC standard interfaces)

In theory we could include all sorts of JDBC drivers at once on the classpath since JDBC works by implementing interfaces and specifying the name of the class that implements a particular interface in the JDBC spec. There is a possibility that JDBC drivers could conflict with each other, but I’m not aware of any JDBC driver pairs where this is the case.

There has been some effort in keeping the size of the built framework small (currently under 27MB), and while it could be much bigger without causing issues for most users it is helpful for various things to keep it small. This is the size consideration, which basically goes back to the ‘optional’ idea, though it is really more like these are only required in certain circumstances (ie using a particular database).

The licensing concern is a bigger deal, for MySQL as well as commercial databases. We could include the Postgres JDBC driver with no concerns here, and generally Postgres is far more ‘free and open source’ than MySQL anyway so I’ve considered updating documentation and general recommendations to default to using Postgres for production servers unless there is a reason to use a different database. A few years ago I would not have recommended this because there are various annoying nuances with Postgres, but Moqui Framework now has workarounds for them, and there were certain things that were more convenient and reliable in MySQL, but many of the advantages of MySQL have evaporated over time.

Anyway, we could have components like moqui-mysql and moqui-postgres, or we could add Gradle tasks to download the JDBC drivers. With either approach hopefully the MySQL license wouldn’t be an issue for Moqui, though a moqui-mysql repo would need a big license warning. For the Postgres JDBC driver it might be an option to just include it by default in moqui.war (in framework/build.gradle).

What I don’t know is how much of a value add this is, or how much this convenience is needed. I’m interested in hearing what others think.

1 Like

You bring up some good points. I guess I was partially curious about why they weren’t included, but it also seemed like a bit more of a pain than it should be to connect a database. I might be wrong though and don’t understand the jdbc database thing completely.

Maybe there is no need to directly include the binaries in the repository while still being available. In my case it was a simple dependency declaration runtime 'org.postgresql:postgresql:42.2.20 followed by a copy to the lib directory:

task copyPythysCommon {
    doLast {
        copy {
            from("${buildDir}/libs") {
                include '**/*.jar'
            from(configurations.runtime -
                 project(':framework').configurations.runtime -
            into "${rootDir}/runtime/lib"
1 Like

In my case, when I developed the OA with the Moqui in 2015. I just download the postgresql jdbc driver jar with browser, and place it to the runtime/lib folder, and make the related config changes to the config/ files.
The OA has been running for 5+ years and is still working very well without any reboot and maintain

1 Like