Add org.jooq.AutoForcedType to auto-detect Converter and Binding types from the classpath of the code generator

[lukaseder]

jOOQ 3.17 added support for auto-configuration of jooq-postgres-extensions data type bindings if found on the classpath (#10763). This is very convenient for the known built-in types for cidr, inet, and hstore (and more in the future).

But the mechanism could also be useful for custom data types implemented by end users, who know they want to apply those on all of their code generation, by default.

To configure this, an annotation could be added to Converter or Binding classes. It would reflect most of the ForcedType contents:

@interface ForcedType {
    int priority() default 0;
    String userType();
    String excludeExpression();
    String includeExpression();
    String sql();
    String excludeTypes();
    String includeTypes();
    Nullability nullability();
    ForcedTypeObjectType objectType();
}

Once available, the implementation of #10763 will be retrofitted to use this annotation, instead.

It's not clear yet where the annotation will be located:

• In jooq / org.jooq it would be accessible to jooq-postgres-extensions, but it couldn't access the org.jooq.meta.jaxb.* types.
• In jooq-meta / org.jooq.meta it could access the org.jooq.meta.jaxb.* types, but it wouldn't be accessible to jooq-postgres-extensions

How we scan the classpath is still open. A spring dependency should be avoided, but is certainly an option.

[axelfontaine]

My vote clearly goes towards

In jooq / org.jooq it would be accessible to jooq-postgres-extensions, but it couldn't access the org.jooq.meta.jaxb.* types.

Keeping jOOQ a zero dependency library (which unfortunately it isn't anymore, but it hasn't drifted too far yet) should still be the north star to follow.

Adding a new dependency on JAXB or Spring would be a mistake that would negatively affect users as it eventually will cause transitive dependency version conflicts down the road. I made this mistake in Flyway 1.x and had to learn this the hard way.

[lukaseder]

jOOQ already has a JAXB API dependency, always did. It used to be part of the JDK since JDK 6. But that's irrelevant to this task. The package name org.jooq.meta.jaxb hints at contents having been xjc generated and JAXB annotated (you can load your code generation configuration from XML using JAXB), but JAXB isn't essential to that API in general.

The Spring dependency could be an option in one of these jOOQ-xyz-extension modules, especially in the code generation ones. But I'm positive there are better options, indeed.