There is already (in existing images) built in support in the /opt/eap/bin/launch/datasource-common.sh script for defining a driver module but the logic is not run by default and the driver module variables are ignored unless a custom install script is used to run the below:

source /usr/local/s2i/install-common.sh
configure_drivers <variables_file>

I verified that if I declare a modules directory in my s2i project root with the module "image" (including the standard directory structure for the module, the module.xml and the jar file(s)) it will automatically be copied to the image (so no custom scripting is needed for the module installation). If the variables were processed automatically (converted into the driver entry in the standalone-openshift.xml, there would be no need for any custom scripting and the driver variables could be declared in the same manner as the datasource variables. To verify this, I customized the /opt/eap/bin/launch/datasource.sh in an image based on the EAP 7.2.8 official image and added the above two lines to the top of the configure() (without providing a script argument to the configure_drivers function - so that the variables are taken directly from the environment) and I confirmed that it worked based only on the environment parameters below and the custom modules directory.

DRIVERS=ORACLE
ORACLE_DRIVER_NAME=ojdbc
ORACLE_DRIVER_MODULE=com.oracle.ojdbc
ORACLE_XA_DATASOURCE_CLASS=oracle.jdbc.xa.client.OracleXADataSource

DB_SERVICE_PREFIX_MAPPING=ExternalDS-ORACLE=EXTDB
EXTDB_NONXA=true
EXTDB_URL=jdbc:oracle:thin:@my.host.com:1521:oracle
EXTDB_JNDI=java:jboss/datasources/oracle-external
EXTDB_DRIVER=ojdbc
EXTDB_USERNAME=me
EXTDB_PASSWORD=mypass
EXTDB_MIN_POOL_SIZE=0
EXTDB_MAX_POOL_SIZE=5
EXTDB_CONNECTION_CHECKER=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
EXTDB_EXCEPTION_SORTER=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter

In most cases, drivers can be published as standard deployments (e.g. included in a deployments directory in the s2i project root) but some drivers may require multiple jars for certain functionality and due to class loading requirements the jars must be packaged as a module. So, more efficient support for driver module deployment would be useful.