How to configure jOOQ auto generator to run on basis of liquibase schema xml file?-CodePudding

I want jOOQ auto-code generator to run on basis of liquibase schema xml file located in resources folder (not on basis of database connection). The configuration part looks like this in pom.xml:

<configuration xmlns="http://www.jooq.org/xsd/jooq-codegen-3.13.4.xsd">
    <generator>
        <database>
            <name>org.jooq.meta.extensions.liquibase.LiquibaseDatabase</name>
            <includes>.*</includes>
            <excludes></excludes>
            <inputSchema>public</inputSchema>

            <properties>
                <property>
                    <key>scripts</key>
                    <value>/liquibase-outputChangeLog.xml</value>
                </property>

                <property>
                    <key>includeLiquibaseTables</key>
                    <value>true</value>
                </property>

                <property>
                    <key>database.liquibaseSchemaName</key>
                    <value>public</value>
                </property>
            </properties>
        </database>

        <target>
            <packageName>jooqGenerated</packageName>
            <directory>target/generated-sources/jooq</directory>
        </target>
    </generator>
</configuration>

It is not able to generate jOOQ code in the specified folder, says

[ERROR] azure/postgresql/TrackerAzureImpl.java: package ...tables does not exist (for all the tables, I cannot even see elsewhere where jooq code is getting generated),
Also one warning: No schemata were loaded: [WARNING] No schemata were loaded  : Please check your connection settings, and whether your database (and your database version!) is really supported by jOOQ. Also, check the case-sensitivity in your configured <inputSchema/> elements : {=[public]}

Please guide.

CodePudding user response：

This is most likely due to a bug: https://github.com/jOOQ/jOOQ/issues/12997

Explanation and workaround

Behind the scenes, in jOOQ 3.16, the LiquibaseDatabase, DDLDatabase, and JPADatabase all simulate your database migrations using an in-memory H2 database. This might be changed in the future, but that's how it works now. In H2, by default, all identifiers are in upper case, and so is the <inputSchema/> configuration. This means you should be including the PUBLIC schema, not the public schema.

Note that also code generation output will contain references to PUBLIC, not public, so if you want to continue using the LiquibaseDatabase, you'll have to turn off quoting of identifiers at runtime using the RenderQuotedNames setting.

More robust alternative that doesn't simulate Liquibase on H2

Alternatively, you don't have to use the LiquibaseDatabase, as I've mentioned elsewhere. You can also use testcontainers to run an actual migration directly on PostgreSQL, and reverse engineer an actual PostgreSQL database, instead, as described in this blog post.