@Override
    protected void configure() {
        // Don't call super.configure() else it will try to multi-bind AppDbConnProvider as
        // a Datasource which will result in a circular dependency


        // * *******************************************************
        // * ********************** WARNING ************************
        // * *******************************************************
        // *
        // * This approach of having a cross-module module is problematic.
        // * It gets run after all the other modules, so it has
        // * no idea what state each of the other modules is in, e.g. a
        // * cross-module mig written for v7.5 may get run after all the
        // * other modules have been brought up to v7.10 and thus
        // * look different to what this mig expects.
        // *
        // * Leaving it here in case it is we find a way to safely use it.
        // *
        // * *******************************************************
        // * *******************************************************
        // * *******************************************************


        // Bind all the cross-module java migrations here so flyway knows what to run.
        // Don't do any SQL migrations as you can't guarantee that each module is in
        // the same DB/host. Java migrations must inject the dbConnProvider for each
        // module that they want to deal with, accepting that
        // Order doesn't matter here, but you are going to sort them aren't you.
        GuiceUtil.buildMultiBinder(binder(), AbstractCrossModuleJavaDbMigration.class)
                .addBinding(V07_05_00_005__Orphaned_Doc_Perms.class);
    }
This DB module is a bit special. The aim is run java only flyway migrations across all
dbConnProviders, so we can do cross-module migrations. You can't do SQL migrations as
each module could potentially be on a different database instance/connection.
stroom-app/src/main/java/stroom/app/db/migration/CrossModuleDbMigrationsModule.java